Network Working Group Eiji Oki (NTT) Internet Draft Takashi Kurimoto (NTT) Expiration Date: April 2005 Ichiro Inoue (NTT) Kohei Shiomoto (NTT) October 2004 Requirements for Path Computation Element in GMPLS and IP/MPLS Networks draft-oki-pce-gmpls-req-01.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than a "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Oki et al. [Page 1] Oki et al. draft-oki-pce-gmpls-req-01.txt October 2004 Abstract Path Computation Element (PCE) provides functions of traffic engineering in Generalized Multi-Protocol Label Switching (GMPLS) and IP/MPLS net- works. In IP/MPLS networks, PCE provides MPLS LSP routes with con- straints. In GMPLS networks, PCE provides GMPLS LSP routes and optimal virtual network topology reconfiguration control, and jugdes on whether a new lower-region LSP should be established when a higher-region LSP is requested. PCE also handles interworking between GMPLS and IP/MPLS net- works, both of which will coexist at some point during the migration process. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. 1. Introduction Path Computation Element (PCE) provides functions of traffic engineering in Generalized Multi-Protocol Label Switching (GMPLS) and IP/MPLS net- works. In IP/MPLS networks, PCE provides MPLS LSP routes with con- straints. In GMPLS networks, PCE provides GMPLS LSP routes and optimal virtual network topology reconfiguration control, and judges on whether a new lower-region LSP should be established when a higher-region LSP is requested. PCE also handles interworking between GMPLS and IP/MPLS net- works, both of which will coexist at some point during the migration process [OKI-INTERWORK]. GMPLS extends MPLS to support various switching technologies [GMPLS- ARC]. GMPLS enables us to control a packet switching network, layer 2 switching networks such as asynchronous transfer mode (ATM) and Ether- net, TDM networks such as synchronous digital hierarchy/synchronous optical network (SDH/SONET), lambda and fiber networks all at once. A GMPLS-based multi-region network architecture is addressed in [MRN_REQ][MRN_EXT]. Multi-region traffic engineering in GMPLS networks increase network resource efficiency, because all the network resources are taken into account at the same time. However, in GMPLS multi-region network environments, traffic engineering becomes more complicated, com- pared with that in single-region network environments. Multi-region traffic engineering includes LSPs route calculation, opti- mal virtual network topology calculation, and judgement on whether a new lower-region LSP should be established when a higher-region LSP is Oki et al. [Page 2] Oki et al. draft-oki-pce-gmpls-req-01.txt October 2004 requested. Multi-region traffic engineering also includes control of virtual network topology reconfiguration, which is triggered by traffic demand change, by topology change, and by network failure. Single- region traffic engineering is a subset of multi-region traffic engineer- ing. For example, let us consider hierarchical label switched paths (LSPs) [LSP-HIERARCHY], where a higher-region LSP uses a lower-region LSP as a TE-link. When the higher-region LSP is setup, it is necessary to judge whether new lower-region LSPs should be established for forwarding adja- cency LSPs (FA-LSPs), or existing lower-region LSPs should be used for FA-LSPs. Judgement such as whether new LSPs should be established or existing LSPs should be used depends on the network providers' traffic- engineering policy. This draft describes requirements for Path Computation Element (PCE) in GMPLS and IP/MPLS networks. Section 2 describes an issue on functional, or logical, separation between PCE and GMPLS node. Section 3 presents several traffic engineering scenarios, where PCE is involved. Section 4 describes PCE placement scenarios. Section 5 describes PCE functional scenarios. Section 6 describes requirements of PCE. Section 7 describes nodal requirements related to PCE. 2. Functional separation between PCE and GMPLS node 2.1. GMPLS node A GMPLS node handles GMPLS protocols. When a GMPLS node is a border node between GMPLS and IP/MPLS networks, the GMPLS node handles both GMPLS and IP/MPLS protocols. 2.2. Network providers' perspective Traffic-engineering policies are different among network providers. For example, when the higher-region LSP is setup, it is necessary judged whether new lower-region LSPs should be established, or existing lower- region LSPs should be used. The judgement, which is performed by PCE, depends on network providers' policy. PCE performance affects the rev- enue of network providers. Network providers want to have their own PCE, because they want to choose appropriate algorithms, which depend on their policies. Oki et al. [Page 3] Oki et al. draft-oki-pce-gmpls-req-01.txt October 2004 2.3. Venders' perspective It is not desirable to implement PCE that considers all the requirements from network providers. A complicated PCE may also cause the node to degrade its processing capability. 2.4. PCE implementation Two approaches for PCE implementation are considered. One is that PCE is implemented as a part of a GMPLS node. PCE is functionally separated from a GMPLS node, from network providers' point of view. The other is that PCE is separately functionally implemented in a GMPLS node. From the above considerations in Sections 2.1 and 2.2, it is desirable to functionally separate PCE from a GMPLS node so that network providers choose their own PCE. 3. Traffic engineering scenarios This section describes key topics of traffic engineering in GMPLS and IP/MPLS networks. Multi-region traffic engineering are mainly described. 3.1. Virtual network topology optimization Two-region GMPLS networks are considered. Discussion on more than two regions can be easily extended in a similar way. Assume that the higher- region network is an IP-packet region network, while the lower-region is an optical network based on TDM or Lambda switching network. The band- width granularity of the lower region is coarse. For example, the band- width is equal to 2.5Gbit/s or 10Gbit/s. On the other hand, the granu- larity of the higher region is flexible and well engineered. Consider the case in which source and destination IP routers request packet (higher-region) LSPs with specified bandwidths. Higher-region LSPs are routed on the optical network that consists of optical (lower- region) LSPs. When the specified packet LSP bandwidths are much smaller than the lower-region LSP bandwidth, the one-hop lower-region LSP between the source-destination IP routers is not fully utilized. In order to utilize network resources, low-speed higher-region LSPs should be efficiently merged at some transit nodes into high-speed lower-region LSPs. There are two main options for routing a higher-region LSP over the optical network: single hop routes or multiple hop routes. Whether low-speed traffic streams should be groomed or not depends on the net- work resource availability such as the number of available wavelengths and the number of available ports in the packet-switching fabric. Oki et al. [Page 4] Oki et al. draft-oki-pce-gmpls-req-01.txt October 2004 Lower-region LSPs form network topology, which is used for routing of higher-region LSPs. The network topology formed by lower-region LSPs is called a virtual network topology. There are on-line and off-line approaches for configuring virtual net- work topologies. Since it is difficult to predict traffic demands pre- cisely, the on-line approach may be realistic and useful in utilizing the network resources more fully and maximizing the revenue from the given resources. Virtual network topology optimization may be performed in a distributed manner, or in a centralized manner. 3.2. Interworking between GMPLS and IP/MPLS networks IP/MPLS and GMPLS networks will coexist at some point in time in the migration process. Such IP/MPLS nodes that do not support GMPLS proto- cols must also operate with GMPLS networks. Migration scenarios from IP/MPLS networks to GMPLS networks that illustrate the issues for rout- ing and signaling are presented in [OKI-INTERWORK]. Consider an MPLS LSP that is established from an MPLS source node to an MPLS destination node via a GMPLS network. The GMPLS network provides a link, which is a GMPLS LSP, for the MPLS LSP. The GMPLS LSP is consid- ered as a lower-region LSP, while the MPLS LSP is considered as a higher-region LSP. In other words, a lower-region LSP is established by GMPLS nodes, while a higher-region LSP is established by MPLS nodes. 3.3. Triggered lower-region LSP setup 3.3.1. Overview of triggered lower-region LSP setup In the triggered lower-region LSP setup, higher-region traffic increase or a higher-region LSP setup invokes the lower-region LSP setup when the lower-region LSP setup is needed. The triggered lower-region LSP setup are required in the following cases. Case 1: When a higher-region LSP setup is processed, a new lower-region LSP is setup, Case 1-1: because there is no lower-region LSP whose residual bandwidth is larger than the requested higher-region bandwidth, or Case 1-2: because the network provider judges that establishing a new lower-region LSP is more cost effective than using an existing lower- region LSP even it is available. Oki et al. [Page 5] Oki et al. draft-oki-pce-gmpls-req-01.txt October 2004 Case 2: higher-region traffic volume increases, but a lower-region residual LSP bandwidth is not enough to transmit the higher-region traf- fic with a certain quality of service. Note that the higher-region traffic and LSP includes ones in IP/MPLS networks, as is described in Section 3.2. Since the lower-region LSP setup triggered by higher-region traffic increase (case 2) can be classified in a subset of a scenario of the virtual network topology reconfiguration, as described in Section 3.4, only the lower-region LSP setup triggered by the higher-region LSP setup (case 1) is considered in Section 3.3. Figure 1 shows the framework of multi-region routing as an one-line approach. If a new lower-region LSP must be setup to support higher- region LSP routing, a lower-region LSP setup request is invoked and lower-region LSP routing is performed. The lower-region LSP-routing result is returned back to the higher-region LSP routing procedure for confirmation of its acceptability. This process is iterated until the desired result is obtained. If successful, the multi-region routing pro- cedure notifies its acceptance for the higher-region LSP setup request. +-------------------------------+ |Higher-region LSP setup request| +-------------------------------+ | v +-----------------+ +-------------------------------+ | Lower-region |--------->|Higher-region LSP accept/reject| | LSP routing|<---------+-------------------------------+ +-----------------+ ^ | | v | +------------------------------+ | |Lower-region LSP setup request| | +------------------------------+ | | | v | +------------------------+ | |Lower-region LSP routing|---------+ +------------------------+ Figure 1 Framework for multi-region routing. In multi-region routing, there are mainly two possible routing policies. When a new higher-region LSP is requested with specified bandwidth, both policies first try to allocate the new requested higher-region LSP to an existing lower-region LSP that directly connects the source and destina- tion nodes. If such a lower-region LSP (existing) is not available, the Oki et al. [Page 6] Oki et al. draft-oki-pce-gmpls-req-01.txt October 2004 two policies adopt different procedures. Policy 1 tries to find a series of available existing lower-region LSPs with two or more hops that con- nect source and destination nodes. On the other hand, policy 2 tries to setup a new one hop lower-region LSP between source and destination nodes. Which policy should be adopted depends on available network resources such as link and port resources. PCE should judge whether new lower- region LSPs should be established, or existing lower-region LSPs should be used. PCE provides LSP routes for both region LSPs if it is neces- sary. The LSP routes may be specified as a "explicit" or " loose" route. 3.3.2. Two approaches for triggered lower-region LSP setup To achieve triggered lower-region LSP setups, there are two possible approaches. The first approach is that PCE participates in both route calculation of both region LSPs and the management of hierarchical signaling including initiating the lower-region LSP setup. The GMPLS node does not have to manage multi-region hierarchical signaling. The GMPLS node can handle two single-region LSP establishments separately. The second approach is that PCE participates only in the route calcula- tion of both region LSPs and does not have to handle the management of hierarchical signaling. The GMPLS node handles multi-region hierarchical signaling. More messages between the GMPLS node and PCE need to be defined in the first approach than the second approach. In the first approach, PCE more involves in multi-region traffic engineering, but the GMPLS node less does. Vice versa in the second approach. A GMPLS node that supports only single-region traffic engineering prefers adopting the first approach to adopting the second approach. This is because a single-region supporting GMPLS node can support multi- region traffic engineering in corporation with PCE as long as PCE inter- faces are implemented. 3.4. Virtual network topology reconfiguration A virtual network topology should be optimized, or reconfigured, so that a set of traffic demand is efficiently carried, considering available network resources such as ports and links. Oki et al. [Page 7] Oki et al. draft-oki-pce-gmpls-req-01.txt October 2004 Procedures of a virtual network topology reconfiguration includes lower- region LSP setup, lower-region LSP release, and higher-region LSP rerouting according to the virtual network topology change. A virtual network topology reconfiguration are required in the following cases. Case 1: higher-region traffic volume increases, but a lower-region residual LSP bandwidth is not enough to transmit the higher-region traf- fic with a certain quality of service. Case 2: Since higher-region traffic volumes between source and destina- tion nodes are dramatically fluctuated, a fixed virtual network topology is not able to provide a certain quality of service, or it is no longer an optimal topology. For example, traffic fluctuations may occur due to differences of user traffic patterns between day and night times. It may occur due to appearances of new services or new servers. Case 3: Topology configurations are changed when physical nodes or links are added/deleted, or when nodal configurations are changed. Case 4: Since network failures occur, existing lower-region LSPs are not available. Higher-region traffic transmitted through the fault lower- region LSPs need to be rerouted. If no possible reroute to save the traffic is found on a current virtual network topology, a virtual net- work topology reconfiguration is necessary. Thus, a virtual network topology reconfiguration may be triggered by traffic demand change (cases 1-2), by topology change (case 3), or by network failure (case 4). 3.5. Single-region traffic engineering Single-region traffic engineering is a subset of multi-region traffic engineering, as is described in Sections 3.1-3.4. PCE supports to pro- vide an LSP route request in a single-region environment. 4. PCE placement scenarios A PCE is placed in a GMPLS network in two possible ways. One way is that each PCE is attached to each GMPLS node, as shown in Figure 2. A PCE behaves as a part of functions in a corresponding GMPLS node. PCE processing load does not dramatically increase as the number of nodes in the networks increases. Traffic engineering is performed in a dis- tributed manner. Oki et al. [Page 8] Oki et al. draft-oki-pce-gmpls-req-01.txt October 2004 Distributed traffic engineering mechanisms, including traffic engineer- ing database (TEDB) synchronization between PCEs, algorithm synchroniza- tion, LSP establishment/release sequence synchronization, etc., are needed. Detail TEDB information is described in Section 5.2 +---+ +---+ +---+ |PCE| |PCE| |PCE| +---+ +---+ +---+ | | | +----------+ +----------+ +----------+ |GMPLS node|--|GMPLS node|--|GMPLS node| +----------+ +----------+ +----------+ Figure 2 PCE that communicates with one GMPLS node. The other way is that a PCE communicates with more than one GMPLS node, as shown in Figure 3. PCE processing load may increase as the number of nodes attached to PCE. In an extreme case that there are one PCE in the GMPLS network, traffic engineering may be performed in a centralized manner. +---+ +-----------|PCE|-----------+ | +---+ | | | | +----------+ +----------+ +----------+ |GMPLS node|--|GMPLS node|--|GMPLS node| +----------+ +----------+ +----------+ Figure 3 PCE that communicates with more than one GMPLS node. 5. PCE functional scenarios 5.1. Overview PCE provides functions of traffic engineering in GMPLS and IP/MPLS net- works. In IP/MPLS networks, PCE provides MPLS LSP routes with con- straints. In GMPLS networks, PCE provides GMPLS LSP routes and optimal virtual network topology reconfiguration control, and judges on whether a new lower-region LSP should be established when a higher-region LSP is requested. PCE also handles interworking between GMPLS and IP/MPLS net- works, both of which will coexist at some point during the migration process. A PCE model in terms of inputs to PCE and outputs from PCE are as fol- lows. Oki et al. [Page 9] Oki et al. draft-oki-pce-gmpls-req-01.txt October 2004 +------+ +---+ +-------+ |Inputs|--->|PCE|--->|Outputs| +------+ +---+ +-------+ Figure 4 Inputs and outputs of PCE Inputs to PCE and outputs from PCE for possible scenarios are summarized as follows. Inputs to PCE Updated information of TE links (see Section 5.2) Route request triggered by higher-region LSP setup Route request in single-region TE Lower-region LSP setup response Lower-region LSP release response Higher-region LSP route change response Trigger of traffic demand change Trigger of topology change Trigger of network failure Outputs from PCE: Route response Lower-region LSP setup request Lower-region LSP release request Higher-region LSP route change request Inputs and outputs for each scenarios are described in Sections 5.3-5.5. 5.2. Collection of TE-link information PCE collects TE-link information, which is stored in its TEDB. First, TE-link information may be collected by using routing protocols of OSPF/IS-IS [RFC2338][RFC3630][GMPLS-OSPF] if PCE is configured as a OSPF/ISIS peer node. Second, TE-link information may be collected by monitoring link-state advertisement passing through some control-plane links between/among OSPF/ISIF peer nodes. Third, TE-link information may be collected by specific protocols between PCE and a GMPLS node such as SNMP or new ones. In the collection of TE-link information that is not included in link-sate advertisements, the third mechanism should be adopted. Otherwise, routing protocols needs to be extended to advertise TE-link information that is not included in link-sate advertisements. A GMPLS node keeps information of LSPs as TE links. The TE-link informa- tion includes, Interface identifiers Reserved bandwidth GMPLS specific parameters such as switch type, encoding type, and GPID Protection type and link type Oki et al. [Page 10] Oki et al. draft-oki-pce-gmpls-req-01.txt October 2004 SRLG LSP identification (LSP ID, Tunnel ID, SA, DA) Measured traffic volume passing through LSP LSP route, etc. Five items from the top are advertised as TE-link information with Opaque LSA [GMPLS-OSPF] when the LSP is considered as FA LSP, but others are not. PCE calculates a route based on constraints and TE-link information. PCE provides the route with the GMPLS node when it is requested. PCE calcu- lates a virtual network topology to be reconfigured based on TE-link information and controls LSP establishments and releases to reconfigure a virtual network topology. 5.3. Triggered lower-region LSP setup As described in Section 2, there are two possible approach in the lower- region LSP setup triggered by higher-region LSP setup. 5.3.1. First approach An example of the first approach is in the following [OKI-GTEP]. PCE GMPLS node | | | Route Request | |<----------------------------------------| | | | Lower-region LSP Setup Request* | |---------------------------------------->| | | | Lower-region LSP Setup Response* | |<----------------------------------------| | | | Route Response | |---------------------------------------->| | | *LSP Setup Request/LSP Setup Response appear only when the lower-region LSP needs to be established. Figure 4 Triggered lower-region LSP setup procedure (first approach) Step 1: The GMPLS node is requested to setup a higher-region LSP. The node may be an ingress node, or an transit node from the high-region Oki et al. [Page 11] Oki et al. draft-oki-pce-gmpls-req-01.txt October 2004 LSP's point of view. Step 2: If at least one condition in the following is satisfied, go to Step 3. 1. In the case of an ingress node, Explicit Route is not speci- fied. In the case of a transit node, Explicit Route Object is included in a Path Message. 2. When Explicit Route is specified, the next hop node is specified as Loose. 3. When Explicit Route is specified and the next hop node is specified as "Strict", there is no TE-link that satis- fies constraints such as bandwidth between the node and the next hop node. Otherwise, go to Step 7. Step 3. The GMPLS node requests a route of the higher-region LSP to PCE Step 4. PCE requires PCE to setup a lower-region LSP if it is necessary. Otherwise, go to Step 6. Step 5. The GMPLS node tries to setup the lower-layer LSP and returns the result whether the LSP setup succeeds to PCE. When the LSP setup succeeds, the result includes LSP_TUNNEL_IF_ID for the FA LSP. LSP_TUN- NEL_IF_ID is used to specify Explicit Route Object for the higher-region LSP. Step 6. PCE responds to the GMPLS node by specifying the route of the higher-region LSP. The specified route is formatted as Explicit Route Object that is carried in a Path message. Then, go to Step 7. Step 7. Signaling procedure starts as an ingress node, or continues as an transit node for the higher-region LSP, according to the route speci- fied by PCE. Inputs to PCE and outputs from PCE are as follows. Inputs to PCE: Updated information of TE links (see Section 5.2) Route request triggered by higher-region LSP setup with constraints of LSP to be setup including GMPLS specific parameters Lower-region LSP setup response Outputs from PCE: Route response Lower-region LSP setup request with constraints of LSP to be setup including GMPLS specific parameters 5.3.2. Second approach Oki et al. [Page 12] Oki et al. draft-oki-pce-gmpls-req-01.txt October 2004 PCE GMPLS node | | | Route Request | |<----------------------------------------| | | | Route Response | |---------------------------------------->| | | Figure 5 Triggered lower-region LSP setup procedure (Second approach) An example of the second approach is in the following. Step 1: The GMPLS node is requested to setup an higher-region LSP. The node may be an ingress node, or an transit node from the high-region LSP's point of view. Step 2: If at least one condition in the following is satisfied, go to Step 3. 1. In the case of an ingress node, Explicit Route is not speci- fied. In the case of a transit node, Explicit Route Object is included in a Path Message. 2. When Explicit Route is specified, the next hop node is specified as Loose. 3. When Explicit Route is specified and the next hop node is specified as "Strict", there is no TE-link that satis- fies constraints such as bandwidth between the node and the next hop node. Otherwise, go to Step 6. Step 3. The GMPLS node requests a route of the higher-region LSP. to PCE. Step 4. PCE provides the route of the higher-region LSP. If necessary, it also provides the route of a lower-region LSP to be setup. Step 5. In case of the necessary of the lower-region LSP establishment, the GMPLS node tries to setup the lower-region LSP, according the speci- fied route provided by PCE. If signaling procedure of the lower-region LSP setup is completed, go to Step 6. Step 6. Signaling procedure of the higher-region LSP starts as an ingress node, or continues as an transit node for the higher-region LSP, according to the route specified by PCE. Inputs to PCE and outputs from PCE are as follows. Inputs to PCE: Updated information of TE links (see Section 5.2) Route request triggered by higher-region LSP setup with constraints of LSP to be setup including GMPLS specific parameters Oki et al. [Page 13] Oki et al. draft-oki-pce-gmpls-req-01.txt October 2004 Outputs from PCE: Route response 5.4. Virtual network topology reconfiguration A virtual network topology reconfiguration may be triggered by traffic demand change, by topology change, or by network failure. In the fol- lowing subsections, each reconfiguration is described. 5.4.1. Virtual network topology reconfiguration triggered by traffic demand change To achieve virtual topology reconfiguration triggered by traffic demand change, the following functions of PCE and the GMPLS node are needed. The virtual topology reconfiguration trigger may be issued by a GMPLS node or PCE. PCE collects TE-link information, periodically, when some values are changed, or when some measured values exceed specified thresholds at GMPLS nodes. The calculation of the reconfigured virtual topology may be performed periodically, when some LSP values are changes, or threshold-based. PCE controls virtual network topology reconfiguration according to the calculation results. When a virtual network topology is reconfigured, "make-before-break" procedures for established higher-region LSPs should be adopted so that service disruption can be avoided. Oki et al. [Page 14] Oki et al. draft-oki-pce-gmpls-req-01.txt October 2004 PCE GMPLS node | | | Traffic demand change trigger | |<----------------------------------------| | | | Lower-region LSP setup request* | | Lower-region LSP release request* | | Higher-region LSP route change request* | |---------------------------------------->| | | | Lower-region LSP setup response* | | Lower-region LSP release response* | | Higher-region LSP route change response*| |<----------------------------------------| | | *The order of these requests and responses depends on reconfiguration procedures. Figure 6 Virtual network topology reconfiguration triggered by traffic demand change issued by GMPLS node PCE GMPLS node | | | Traffic demand change trigger | |---------------------------------------->| | | | Lower-region LSP setup request* | | Lower-region LSP release request* | | Higher-region LSP route change request* | |---------------------------------------->| | | | Lower-region LSP setup response* | | Lower-region LSP release response* | | Higher-region LSP route change response*| |<----------------------------------------| | | *The order of these requests and responses depends on reconfiguration procedures. Figure 7 Virtual network topology reconfiguration triggered by traffic demand change issued by PCE Inputs to PCE and outputs from PCE are as follows. Inputs to PCE: Updated information of TE links (see Section 5.2) Oki et al. [Page 15] Oki et al. draft-oki-pce-gmpls-req-01.txt October 2004 Traffic demand change trigger issued by GMPLS node Lower-region LSP setup response Lower-region LSP release response Higher-region LSP route change response Outputs from PCE: Traffic demand change trigger issued by PCE Lower-region LSP setup request Lower-region LSP release request Higher-region LSP route change request 5.4.2. Virtual network topology reconfiguration triggered by topology change The calculation of the reconfigured virtual topology is performed when topology is changed. The virtual topology reconfiguration trigger may be issued by a GMPLS node or PCE. PCE controls virtual network topology reconfiguration according to the calculation results. When a virtual network topology is reconfigured, "make-before-break" procedures for established LSPs should be adopted so that service dis- ruption can be avoided. PCE GMPLS node | | | Network topology change trigger | |<----------------------------------------| | | | Lower-region LSP setup request* | | Lower-region LSP release request* | | Higher-region LSP route change request* | |---------------------------------------->| | | | Lower-region LSP setup response* | | Lower-region LSP release response* | | Higher-region LSP route change response*| |<----------------------------------------| | | *The order of these requests and responses depends on reconfiguration procedures. Figure 8 Virtual network topology reconfiguration triggered by traffic demand change issued by GMPLS node Oki et al. [Page 16] Oki et al. draft-oki-pce-gmpls-req-01.txt October 2004 PCE GMPLS node | | | Network topology change trigger | |---------------------------------------->| | | | Lower-region LSP setup request* | | Lower-region LSP release request* | | Higher-region LSP route change request* | |---------------------------------------->| | | | Lower-region LSP setup response* | | Lower-region LSP release response* | | Higher-region LSP route change response*| |<----------------------------------------| | | *The order of these requests and responses depends on reconfiguration procedures. Figure 9 Virtual network topology reconfiguration triggered by traffic demand change issued by PCE Inputs to PCE and outputs from PCE are as follows. Inputs to PCE: Updated information of TE links (see Section 5.2) Topology change trigger issued by GMPLS node Lower-region LSP setup response Lower-region LSP release response Higher-region LSP route change response Outputs from PCE: Topology change trigger issued by PCE Lower-region LSP setup request Lower-region LSP release request Higher-region LSP route change request 5.4.3. Virtual network topology reconfiguration triggered by network failure When network failure occurs, virtual topology reconfiguration should be performed as fast as possible so that the degradation of network perfor- mance can be avoided. The virtual topology reconfiguration trigger may be issued by a GMPLS node or PCE. Procedures of the virtual network topology reconfiguration is similar to that triggered by traffic demand change and topology change, but the Oki et al. [Page 17] Oki et al. draft-oki-pce-gmpls-req-01.txt October 2004 network failure triggered operation requires urgent actions as a emer- gent case. PCE GMPLS node | | | Network failure change trigger | |<----------------------------------------| | | | Lower-region LSP setup request* | | Lower-region LSP release request* | | Higher-region LSP route change request* | |---------------------------------------->| | | | Lower-region LSP setup response* | | Lower-region LSP release response* | | Higher-region LSP route change response*| |<----------------------------------------| | | *The order of these requests and responses depends on reconfiguration procedures. Figure 10 Virtual network topology reconfiguration triggered by traffic demand change issued by GMPLS node PCE GMPLS node | | | Network failure change trigger | |---------------------------------------->| | | | Lower-region LSP setup request* | | Lower-region LSP release request* | | Higher-region LSP route change request* | |---------------------------------------->| | | | Lower-region LSP setup response* | | Lower-region LSP release response* | | Higher-region LSP route change response*| |<----------------------------------------| | | *The order of these requests and responses depends on reconfiguration procedures. Figure 11 Virtual network topology reconfiguration triggered by traffic demand change issued by PCE Inputs to PCE and outputs from PCE are as follows. Oki et al. [Page 18] Oki et al. draft-oki-pce-gmpls-req-01.txt October 2004 Inputs to PCE: Updated information of TE links (see Section 5.2) Network failure change trigger issued by GMPLS node Lower-region LSP setup response Lower-region LSP release response Higher-region LSP route change response Outputs from PCE: Lower-region LSP setup request Lower-region LSP release request Higher-region LSP route change request 5.5. Single-region traffic engineering PCE GMPLS node | | | Route Request | |<---------------------------| | | | Route Response | |--------------------------->| | | Figure 12 Single-region traffic engineering An example of the single-layer LSP route request procedure is in the following. Step 1. The GMPLS node is requested to setup an LSP. Step 2. The GMPLS node requests a route of the LSP to PCE. Step 3. PCE sends the GMPLS node the LSP route. Inputs to PCE and outputs from PCE are as follows. Inputs to PCE: Updated information of TE links (see Section 5.2) Route request in single-region TE Outputs from PCE: Route response Oki et al. [Page 19] Oki et al. draft-oki-pce-gmpls-req-01.txt October 2004 6. PCE Requirements 6.1. Triggered lower-region LSP setup Lower-region LSP setup triggered by the high-layer LSP setup should be supported. When the higher-layer LSP is setup, PCE should judge whether new lower-layer LSPs should be established as forwarding adjacency LSPs (FA-LSPs), or existing lower-layer LSPs should be used as FA-LSPs. PCE provides LSP routes for both layer LSPs if it is necessary. The LSP routes may be specified as a "explicit" or " loose" route. To achieve triggered lower-region LSP setups, there are two possible approaches. The first approach is that PCE participates in both route calculation of both region LSPs and the management of hierarchical signaling including initiating the lower-region LSP setup. The GMPLS node does not have to manage multi-region hierarchical signaling. The GMPLS node can handle two single-region LSP establishments separately. The second approach is that PCE participates only in the route calcula- tion of both region LSPs and does not have to handle the management of hierarchical signaling. The GMPLS node handles multi-region hierarchical signaling. More messages between the GMPLS node and PCE need to be defined in the first approach than the second approach. In the first approach, PCE more involves in multi-region traffic engineering, but the GMPLS node less does. Vice versa in the second approach. A GMPLS node that supports only single-region traffic engineering prefers adopting the first approach to adopting the second approach. This is because a single-region supporting GMPLS node can support multi- region traffic engineering in corporation with PCE as long as PCE inter- faces are implemented. 6.2. Virtual network topology reconfiguration Virtual network topology reconfigurations triggered by traffic demand change, by topology change, and by network failure should be supported. When a virtual network topology is reconfigured triggered by traffic demand change and by topology change, "make-before-break" procedures for established LSPs should be adopted so that service disruption can be avoided. Oki et al. [Page 20] Oki et al. draft-oki-pce-gmpls-req-01.txt October 2004 When network failure occurs, virtual topology reconfiguration should be performed as fast as possible so that the degradation of network perfor- mance can be avoided. 6.3. Single-region traffic engineering Single-region traffic engineering is a subset of multi-region traffic engineering. PCE should support to provide an LSP route request in a single-region environment. 6.4. Constraints of the route calculation to PCE A GMPLS node should provide constraints for LSP setups for PCE, when the GMPLS node requests a route of the LSP to PCE. Constraints for LSP setups should include GMPLS specific parameters. Example of the GMPLS specific parameters are a switch type, encoding type, GPID, bandwidth, protection type, and link type, which are included in a generalized label request object [RFC3471][RFC3473]. When PCE fails to provide an route that doest not satisfy the con- straints, PCE should optionally includes suggested routes but does not completely satisfy the constraints that enable to find a route. In MPLS networks, [MPLS-COMP] describes examples of relaxation of alternative constraints such as bandwidth and protection type. In GMPLS networks, relaxation of alternative constraints such as switching type, encoding type, GPID, and SRLG should be extended. 6.5. Collection of TE-link information PCE should collect TE-link information. A part of TE-link information is able to be obtained by using routing protocols of OSPF/IS-IS. However, A part of TE-link information that is not included in link-sate advertise- ments is not able to be collected with the routing protocols. Such TE- link information should be collected by specific protocols between PCE and a GMPLS node. A GMPLS node should keep information of LSPs as TE links. The TE-link information includes, Reserved LSP bandwidth GMPLS specific parameters such as switch type, encoding type, GPID, Protection type and link type Measured traffic volume passing through LSP LSP route, etc. Oki et al. [Page 21] Oki et al. draft-oki-pce-gmpls-req-01.txt October 2004 The first and second items are advertised as TE-link information with Opaque LSA [GMPLS-OSPF] when the LSP is considered as FA LSP, but others are not. PCE should collect all TE-link information in the manageable network domain. The LSP information that is stored in LSP database of each GMPLS node should be reported to PCE in a timely manner. LSP database should be updated after LSP establishment/release. A large volume of TE-link information data should be transferred with reliability. 6.6. PCE scalability In GMPLS multi-region network environments, traffic engineering becomes more complicated, compared with that in single-region network environ- ments. Complicated TE algorithms should not degrade PCE scalability in terms of processing capability. 6.7. Interworking GMPLS and IP/MPLS networks PCE should support interworking GMPLS and IP/MPLS networks, both of which will coexist at some point during the migration process [OKI- INTERWORK]. 6.8. Synchronization of TEDBs in PCE and in GMPLS node TEDB in PCEs and GMPLS nodes should be synchronized consistently and quickly. 6.9. Fault-tolerant PCEs PCE should be fault tolerant. 7. Nodal requirements related to PCE 7.1. PCE request mode 7.1.1. PCE mandatory request mode A GMPLS node should have a mandatory request mode where it must request PCE to calculate a route to the destination node whenever the route Oki et al. [Page 22] Oki et al. draft-oki-pce-gmpls-req-01.txt October 2004 needs to be obtained. In this mode, the GMPLS node should not calculate the route with its own CSPF engine. 7.1.2. PCE normal request mode A GMPLS node should have a normal request mode. Consider that a GMPLS node receives a Path message including Explicit Route Object. The next hop node is specified as "Strict", but there is no TE link that satis- fies constraints. The GMPLS node should not issue a Path Error Massage to the upstream node without inquiring the possibility of a lower-region LSP establishment with PCE. The GMPLS node should request the possibility of a lower-region LSP establishment with PCE. The lower-region LSP establishment suggested by PCE should be consistent with the explicit route of the higher-region LSP. 7.2. Network stability in terms of PCE When a GMPLS node is not able to find any available PCE in a managed network domain, a GMPLS node should act as a non-PCE mode. Any PCE failure should not affect data-plane transmission that is already serviced. 8. Intellectual Property Considerations The IETF takes no position regarding the validity or scope of any Intel- lectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this docu- ment or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assur- ances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such propri- etary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this Oki et al. [Page 23] Oki et al. draft-oki-pce-gmpls-req-01.txt October 2004 standard. Please address the information to the IETF at ietf- ipr@ietf.org. 9. IPR Disclosure Acknowledgement By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 10. References [GMPLS-ARC] E. Mannie, "Generalized Multi-Protocol Label Switching Architecture," IETF draft, draft-ietf-ccamp-gmpls-architecture-07.txt, May 2003. [RFC3471] L. Berger et al., "Generalized MPLS - Signaling Functional Description," RFC 3471 , Jan. 2003. [RFC3473] P. Ashwood-Smith et al, "Generalized MPLS Signaling - RSVP-TE Extensions," RFC 3473, Jan. 2003. [RFC2338] J. Moy, "OSPF Version 2," RFC 2328. [RFC3630] D. Katz et al., "Traffic Engineering (TE) Extensions to OSPF Version 2," RFC 3630. [GMPLS-OSPF] K. Kompella and Y. Rekhter, "OSPF Extensions in Support of Generalized MPLS," IETF draft, draft-ietf-ccamp-ospf-gmpls-exten- sions-12.txt, Oct. 2003. (working in progress) [RFC3477] K. Kompella and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol -Traffic Engineering (RSVP-TE)," RFC 3477. (working in progress) [MRN_REQ] K. Shiomoto et al, "Requirements for GMPLS-based multi-region and multi-layer networks," IETF draft, draft-shiomoto-ccamp-gmpls-mrn- reqs-00.txt, Oct. 2004. (work in progress) [MRN_EXT] D. Papadimitriou et al., "Generalized Multi-Protocol Label Switching (GMPLS) Protocol Extensions for Multi-Region Networks (MRN)," IETF draft, draft-papadimitriou-ccamp-gmpls-mrn-extensions-00.txt, Oct. 2004. (work in progress) [LSP-HIERARCHY] K. Kompella and Y. Rekhter, "LSP Hierarchy with General- ized MPLS TE," draft-ietf-mpls-lsp-hierarchy-08.txt, Sep. 2002. (working in progress) Oki et al. [Page 24] Oki et al. draft-oki-pce-gmpls-req-01.txt October 2004 [MPLS-COMP] JP Vasseur et al., "RSVP Path computation request and reply messages," IETF draft, draft-vasseur-mpls-computation-rsvp-03, June 2002. [OKI-GTEP] E. Oki et al., "Generalized Traffic Engineering Protocol", IETF draft, draft-oki-ccamp-gtep-01.txt, October 2004. [OKI-INTERWORK] E. Oki et al, "Migrating from IP/MPLS to GMPLS net- works," IETF draft, draft-oki-ccamp-gmpls-ip-interworking-04.txt, Octo- ber 2004. 11. Authors' Address Eiji Oki NTT Corporation 3-9-11 Midori-cho, Musashino-shi, Tokyo 180-8585, Japan Email: oki.eiji@lab.ntt.co.jp Takashi Kurimoto NTT Corporation 3-9-11 Midori-cho, Musashino-shi, Tokyo 180-8585, Japan Email: kurimoto.takashi@lab.ntt.co.jp Ichiro Inoue NTT Corporation 3-9-11 Midori-cho, Musashino-shi, Tokyo 180-8585, Japan Email: inoue.ichiro@lab.ntt.co.jp Kohei Shiomoto NTT Corporation 3-9-11 Midori-cho, Musashino-shi, Tokyo 180-8585, Japan Email: shiomoto.kohei@lab.ntt.co.jp Oki et al. [Page 25]