CCAMP Working Group Eiji Oki (NTT) Internet Draft Daisaku Shimazaki (NTT) Expiration Date: April 2005 Kohei Shiomoto (NTT) October 2004 Generalized Traffic Engineering Protocol draft-oki-ccamp-gtep-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. E. Oki et al. [Page 1] E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004 Abstract This draft describes a generalized traffic engineering protocol (GTEP). GTEP is a protocol that communicates between a Path Computation Element (PCE) and a GMPLS controller (GMPLS CNTL). A GMPLS CNTL is a controller that handles GMPLS and MPLS protocols such as routing and signaling protocols and controls a GMPLS node. PCE provides a function of traffic engineer- ing, which calculates LSP routes and judges whether a new lower-layer LSP should be established and whether an existing lower-layer LSP should be released. 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 Generalized Multi-Protocol Label Switching (GMPLS) extends MPLS to sup- port various switching technologies. GMPLS enables us to control a packet switching network, layer 2 switching networks such as asyn- chronous transfer mode (ATM) and Ethernet, TDM networks such as syn- chronous 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 increases 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. For example, let us consider hierarchical label switched paths (LSPs) [LSP-HIERARCHY], where a higher-layer LSP uses a lower-layer LSP as a TE-link. When the higher-layer LSP is setup, it is necessary judged whether new lower- layer LSPs SHOULD be established for forwarding adjacency LSPs (FA- LSPs), or existing lower-layer LSPs SHOULD be used for FA-LSPs. It is not realistic that the LSP route calculation engine, or path computation element (PCE), that performs multi-region traffic engineering (MRTE) with several constraints is implemented into all the node. Moreover, judgements such as whether new LSPs SHOULD be established, or existing LSPs SHOULD be used depends on network providers' traffic-engineering policy. Network providers want to have own traffic engineering engine. From vendors' points of view, it is not desirable to implement PCE that considers all the requirements from network providers. A complicated PCE E. Oki et al. [Page 2] E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004 may also cause the node to degrade its processing capability. There- fore, it is reasonable to separate the PCE from a GMPLS controller that handles GMPLS protocols. This draft describes a generalized traffic engineering protocol (GTEP). GTEP is a protocol that communicates between PCE and the GMPLS con- troller (GMPLS CNTL). 2. GTEP Overview 2.1. GTEP Common Definitions All GTEP packets are run over TCP with a GTEP port number The GTEP port number is TBA (to be assigned) by IANA. For the time being, A private port number, which is in the range between 49152 and 65535, is used. +------------------+ | +------+ | | |RSVP | | | |module| | +-----------+ | +------+ | | PCE +---------||---------+ | +-----------+ GTEP | +----+ +------+ | | |LSDB+--+ OSPF | | | +----+ |module| | | +------+ | +------------------+ GMPLS CNTL Figure 1 Communication between PCE and GMPLS CNTL with GTEP. GTEP is a protocol that communicates between PCE and a GMPLS CNTL. A GMPLS CNTL is a controller that handles GMPLS and MPLS protocols and controls a GMPLS node. The GMPLS CNTL handles GMPLS protocols such as signaling and routing protocols. Figure 1 depicts the GMPLS CNTL structure that includes a RSVP module and a OSPF module with a Link State Database (LSDB) PCE provides a function of traffic engineering, which calculates LSP routes and judges whether a new lower-layer LSP SHOULD be established. Applicability of PCE is as follows. For single-layer networks, PCE pro- vides LSP routes considering several constraints. For multi-region net- works, a function of multi-region traffic engineering, which calculates LSP routes and judges whether a new lower-layer LSP SHOULD be E. Oki et al. [Page 3] E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004 established. The detail functions of the GMPLS CNTL and PCE based on GTEP are described in the following subsections. 2.2. GMPLS CNTL Function A GMPLS CNTL is a controller that handles GMPLS and MPLS protocols and controls a GMPLS node. When the GMPLS CNTL tries to setup a new LSP, or receives a Path message from the previous hop node, it requires the PCE to give the LSP route to it. The PCE calculates the LSP route and gives it to the GMPLS CNTL. The GMPLS CNTL establishes the LSP according to the route suggested by the PCE. The PCE requires the GMPLS CNTL to setup a lower-layer LSP if it is nec- essary. In this case, the GMPLS CNTL tries to setup the lower-layer LSP and returns the result whether the LSP setup succeeds to the PCE. When the LSP setup succeeds, the result includes LSP_TUNNEL_IF_ID for the FA LSP. When a Link State Database (LSDB) in the GMPLS CNTL is updated, it sends the updated LSDB information to the PCE. When the GMPLS CNTL is requested to give the LSDB information, it sends the latest LSDB infor- mation to the PCE. 2.3. PCE Function PCE gives the GMPLS CNTL an LSP route when the LSP route is requested by the GMPLS CNTL. The PCE calculates the LSP route by using Traffic Engi- neering Database (TED). TED in the PCE is created by using the informa- tion of the LSDB in the GMPLS CNTL. The PCE requires the GMPLS CNTL to setup a lower-layer LSP if it is nec- essary. In this case, the GMPLS CNTL tries to setup the lower-layer LSP and returns the result whether the LSP setup succeeds to the PCE. When the LSP setup succeeds, the result includes LSP_TUNNEL_IF_ID for a FA LSP. The PCE creates a route of the requested higher-layer LSP by using LSP_TUNNEL_IF_ID as interfaces of TE-links and send the route to the GMPLS CNTL. When a Link State Database (LSDB) in the GMPLS CNTL is updated, it sends the updated LSDB information to the PCE. According to the LSDB update, the PCE also updates the TED. When the PCE is booted, it requests the information of LSDB to the GMPLS CNTL. The GMPLS CNTL sends the infor- mation of LSDB to the PCE. Then, the PCE creates TED. E. Oki et al. [Page 4] E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004 3. GTEP Procedure 3.1. PCE Boot Sequence PCE GMPLS CNTL | | | ConfigRequest Message | |-------------------------------->| | | | ConfigResponse Message | |<--------------------------------| | | | LsRequest Message | |-------------------------------->| | | | LsResponse Message | |<--------------------------------| | | Figure 2 PCE boot sequence. Step 1. The PCE is booted. Step 2. The PCE sends ConfigRequest Message to the GMPLS CNTL to request configuration in the GMPLS CNTL. Step 3. The GMPLS CNTL sends ConfigResponse Message to the PCE to give the configuration. Step 4. The PCE sends LsRequest Message to the GMPLS CNTL to request the LSDB information in the GMPLS CNTL. Step 5. The GMPLS CNTL send LsResponse Message to the PCE to give the LSDB information. 3.2. LSP Setup Sequence for Single Layer Case PCE GMPLS CNTL | | | RouteRequest Message | |<--------------------------------| | | | RouteResponse Message | |-------------------------------->| | | Figure 3 LSP setup sequence for single layer case. E. Oki et al. [Page 5] E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004 Step 1. The GMPLS CNTL is requested to setup an LSP. Step 2. The GMPLS CNTL sends RouteRequest Message to the PCE to ask it to give the LSP route. Step 3. The PCE sends RouteResponse Message to the GMPLS CNTL to give the LSP route. 3.3. LSP Setup Sequence for Two Layer Case PCE GMPLS CNTL | | | RouteRequest Message | |<--------------------------------| | | | LspSetupRequest Message* | |-------------------------------->| | | | LspSetupResponse Message* | |<--------------------------------| | | | RouteResponse Message | |-------------------------------->| | | *The LspSetupRequest/LspSetupResponse Messages appear only when the lower-layer LSP needs to be established. Figure 4 LSP setup sequence for two layer case. Step 1: The GMPLS CNTL is requested to setup an higher-layer LSP. The node that is connected to the GMPLS CNTL MAY be an ingress node, or an transit node from the high-layer 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 CNTL sends RouteRequest Message to the PCE to request a route of the higher-layer LSP. Step 4. The PCE requires the GMPLS CNTL to setup a lower-layer LSP if it E. Oki et al. [Page 6] E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004 is necessary. Otherwise, go to Step 6. Step 5. The GMPLS CNTL tries to setup the lower-layer LSP and returns the result whether the LSP setup succeeds to the PCE. When the LSP setup succeeds, the result includes LSP_TUNNEL_IF_ID for the FA LSP. Step 6. The PCE sends RouteResponse Message that specifies the route of the higher-layer LSP to the GMPLS CNTL. 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-layer LSP, according to the route speci- fied by Explicit Route Object. 3.4. LSP Setup initiated by PCE PCE GMPLS CNTL | | | LspSetupRequest Message* | |-------------------------------->| | | | LspSetupResponse Message* | |<--------------------------------| | | Figure 5 LSP Setup initiated by PCE Step 1. The PCE initiates to require the GMPLS CNTL to setup an LSP, when the PCE determined that a new LSP setup is necessary. The initia- tion is triggered by traffic demand change, network topology change, and network failure. Step 2. The GMPLS CNTL tries to setup the LSP and returns the result whether the LSP setup succeeds to the PCE. When the LSP setup succeeds, the result includes LSP_TUNNEL_IF_ID for the FA LSP. 3.5. LSP Release initiated by PCE PCE GMPLS CNTL | | | LspReleaseRequest Message* | |-------------------------------->| | | | LspReleaseResponse Message* | |<--------------------------------| E. Oki et al. [Page 7] E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004 | | Figure 6 LSP Setup initiated by PCE Step 1. The PCE initiates to require the GMPLS CNTL to release an exist- ing LSP, when the PCE determined that the existing LSP setup is not nec- essary. The initiation is triggered by traffic demand change, network topology change, and network failure. Step 2. The GMPLS CNTL tries to release the LSP and returns the result whether the LSP release succeeds to the PCE. 4. GTEP Message 4.1. Common Header and Common Trailer In addition to the TCP header and standard IP header, all GTEP messages have the following common header and common trailer. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Message Type | Result | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Transaction ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | GTEP Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Message body ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Marker (32 bits, ASCII CODE "GTEP") | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7 Common Header and Common Trailer The Reserved field should be sent as zero and ignored on receipt. All values are defined in network byte order (i.e., big-endian byte order). Version: 8 bits. Protocol version number. This is version 1. Message Type: 8 bits. The following values are defined. 1 = RouteRequest Message 2 = RouteResponse Message 3 = RouteRequestCancel Message 4 = LspSetupRequest Message E. Oki et al. [Page 8] E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004 5 = LspSetupResponse Message 6 = LspReleaseRequest Message 7 = LspReleaseResponse Message 8 = LsUpdate Message 9 = LsRequest Message 10 = LsResponse Message 11 = ConfigRequest Message 12 = ConfigResponse Message Result: 8 bits. A value of "NoSuccessAck" indicates that the request message does not expect a response if the outcome is successful, and a value of "AckAll" indicates that a response is expected if the outcome is successful. In both cases a failure response MUST be generated if the request fails. In a response message, the result field can have two val- ues: "Success" and "Failure". The "Success" and "Failure" results indi- cate success and failure responses, respectively. All messages that belong to the same success response will have the same Transaction Iden- tifier. The following values are defined. 1 = NoSuccessAck 2 = AckAll 3 = Success 4 = Failure Code: 8 bits. Field gives further information concerning the result in a response message. It is mostly used to pass an error code in a failure response but can also be used to give further information in a success response message or an event message. In a request message, the code field is not used and is set to zero. Transaction ID: 24 bits. Used to associate a request message with its response message. For request messages, the controller may select any transaction identifier. For response messages, the transaction identi- fier is set to the value of the transaction identifier from the message to which it is a response. For event messages, the transaction identi- fier SHOULD be set to zero. The Transaction Identifier is not used, and the field is not present, in the adjacency protocol. GTEP Length: 16 bits. Length of the GTEP message including its header fields, defined GTEP message body, and marker field. It is expressed by byte. Marker: 32 bits. This 32-bit filed contains ASCII CODE "GTEP". With the maker field and the length, it is judged whether GTEP messages are cor- rectly sent and received. If the marker field does not contain ASCII CODE "GTEP", it indicates that the GTEP message has a format error. In this case, the TCP connection is disconnected, and the CSPF, which is a client, sets up the TCP connection with the GMPLS CNTL, which is a E. Oki et al. [Page 9] E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004 server, again. 4.2. GTEP Message Format GTEP messages are built using objects. Each object is identified by its Object Class and Class-type. Each object has a name, which is always capitalized in this document. All values are defined in network byte order (i.e., big-endian byte order). The format of the GTEP object is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Class | C-Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ (object contents) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8 GTEP Object Class: 8 bits. The Class indicates the object type. Each object has a name, which is always capitalized in this document. C-Type: 8 bits. Class-type, unique within an Object Class. Values are defined in Section 5. Length: 8 bits. Length of the GTEP object including its header fields and defined GTEP object contents. It is expressed by byte. 4.2.1. RouteRequest Message The RouteRequest message is used when the GMPLS CNTL requests the PCE to give the GMPLS CNTL an LSP route. In the common header, the result is set to 2 and the transaction ID is set to a non-zero value. The contents of the RouteRequest message are built using GTEP objects. The format of the RouteRequest message is as follows: ::= [] [] E. Oki et al. [Page 10] E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004 [] TIME_VALUE is an option and indicates an allowable waiting time from when the RouteRequest message is sent to the PCE until when the RouteRe- sponse message is received from the PCE. If TIME_VALUE is not included, a default allowable waiting time configured by the GMPLS CNTL is used. If the allowable waiting time expires before the RouteResponse message is received, the waiting state is released. DESTINATION_IP_ADDRESS indicates a destination IP address of the LSP route that is requested to be calculated from the node connected to the GMPLS CNTL. DESTINATION_IP_ADDRESS MAY NOT be the same as the destina- tion address of the LSP. DESTINATION_IP_ADDRESS MAY be a router id of a transit node. In a transit node, when an explicit route object in the Path message includes "loose" for a part of the LSP route, the GMPLS CNTL asks the PCE to give the exact route of the LSP that is specified as "loose" by the explicit route in the Path message. On the other hand, in the transit node, when an explicit route object strictly specifies the next hop node but there is no direct TE-link to the next hop node that satisfies the constraints, the GMPLS CNTL sends the RouteRequest message to the PCE by setting DESTINATION_IP_ADDRESS as the next hop node. LABEL_REQUEST includes LSP encoding type, switching type, and informa- tion on the LSP direction, which is uni-direction or bi-direction. By using these values, the type of LSP that should be setup is described. BANDWIDTH indicates the LSP bandwidth. PROTECTION indicates the protection type of LSP that should be setup. PRIMARY_PATH_ROUTE is an option. It is set when the GMPLS CNTL requests the PCE for the route of the secondary LSP that is disjoint from the primary LSP. SECONDARY_PATH_ROUTE is an option. It is set when the GMPLS CNTL requests the PCE for the route of the secondary LSP. 4.2.2. RouteResponse Message The RouteResponse message is used when the GMPLS CNTL gives the PCE an LSP route that is requested by the PCE. In the common header, the result is set to 3 (success) or 4 (failure), and the transaction ID is set to the value that is set by the RouteRequest message. The contents of the RouteResponse message are built using GTEP objects. The format of the RouteResponse message is as follows: ::= [] E. Oki et al. [Page 11] E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004 [] When the result is set to 3 (success), the RouteResponse message includes either or , or both of them, according to the request of the RouteRequest message. In the common header, when the result is set to 4 (failure), the code is defined as follows: Code = 1: Format error of RouteRequest message Code = 2: Failure on the calculation for the requested LSP route. 4.2.3. RouteCancel Message The RouteCancel message is used when the GMPLS CNTL cancels the request that is sent to the PCE as the RouteRequest message. When the PCE receives the RouteCancel message from the GMPLS CNTL, the CSPF stops the LSP route calculation. In the common header, the result is set to 1, and the transaction ID is set to the value that is set by the RouteRequest message. The contents of the RouteCancel mes- sage are built using GTEP objects. The format of the RouteCancel message is as follows: ::= 4.2.4. LspSetupRequest Message The LspSetupRequest message is used when the PCE request the GMPLS CNTL to setup the lower-layer LSP if it is necessary to setup the higher- layer LSP, whose route is requested by the RouteRequest message. In the common header, the result is set to 2, and the transaction ID is set to a non-zero value. The contents of the LspSetupRequest message are built using GTEP objects. The format of the LspSetupRequest message is as fol- lows: ::= [] [] E. Oki et al. [Page 12] E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004 TIME_VALUE is an option and indicates an allowable waiting time from when the LspSetupRequest message is sent to the GMPLS CNTL until when the LspSetupRequest message is receded from the GMPLS CNTL. If TIME_VALUE is not included, a default allowable waiting time configured by the PCE is used. If the allowable waiting time expires before the LspSetupResponse message is received, the waiting state is released. SOURCE_IP_ADDRESS indicates a source IP address of the LSP that is requested to be setup. The node that is connected to the GMPLS node is a source node. DESTINATION_IP_ADDRESS indicates a destination IP address of the LSP that is requested to be setup. LABEL_REQUEST includes LSP encoding type, switching type, and informa- tion on the LSP direction, which is uni-direction or bi-direction. By using these values, the type of LSP that should be setup is described. BANDWIDTH indicates the LSP bandwidth. The GMPLS CNTL SHOULD setup the LSP whose bandwidth is equal to or more than the value indicated by BANDWIDTH. PROTECTION indicates the protection type of LSP that should be setup. PRIMARY_PATH_ROUTE is mandatary. It indicates the route of the primary LSP. SECONDARY_PATH_ROUTE is an option. It is set when the PCE requests the secondary LSP in addition to the primary LSP. 4.2.5. LspSetupResponse Message The LspSetupResponse message is used when the GMPLS CNTL gives the PCE the result of the LSP setup that is requested by the PCE. In the common header, the result is set to 3 (success) or 4 (failure), and the trans- action ID is set to the value that is set by the LspSetupRequest mes- sage. The contents of the LspSetupResponse message are built using GTEP objects. The format of the LspSetupResponse message is as follows: ::= When the result is set to 3 (success), the LspSetupResponse message includes both INGRESS_LSP_TUNNEL_IF_ID and EGRESS_LSP_TUNNEL_IF_ID. In the common header, when the result is set to 4 (failure), both INGRESS_LSP_TUNNEL_IF_ID and EGRESS_LSP_TUNNEL_IF_ID are not included in the LspSetupResponse Message and the code is defined as follows: Code = 1: Format error of LspSetupRequest message E. Oki et al. [Page 13] E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004 Code = 2: Failure on the requested LSP setup. 4.2.6. LspReleaseRequest Message The LspReleaseRequest message is used when the PCE request the GMPLS CNTL to release an existing LSP, when the PCE determined that the exist- ing LSP setup is not necessary. The initiation is triggered by traffic demand change, network topology change, and network failure. In the com- mon header, the result is set to 2, and the transaction ID is set to a non-zero value. The contents of the LspSetupRequest message are built using GTEP objects. The format of the LspReleaseRequest message is as follows: ::= [] TIME_VALUE is an option and indicates an allowable waiting time from when the LspReleaseRequest message is sent to the GMPLS CNTL until when the LspReleaseRequest message is receded from the GMPLS CNTL. If TIME_VALUE is not included, a default allowable waiting time configured by the PCE is used. If the allowable waiting time expires before the LspSetupResponse message is received, the waiting state is released. SOURCE_IP_ADDRESS/DESTINATION_IP_ADDRESS indicates a source/destination interface IP address of the LSP that is requested to be released if the both-end FA addresses is numbered. INGRESS_LSP_TUNNEL_IF_ID/EGRESS_IP_ADDRESS indicates a source/destina- tion unnumbered address of the LSP that is requested to be released. Either SOURCE_IP_ADDRESS/DESTINATION_IP_ADDRESS or INGRESS_LSP_TUN- NEL_IF_ID/EGRESS_IP_ADDRESS is used. 4.2.7. LspReleaseResponse Message The LspReleaseResponse message is used when the GMPLS CNTL gives the PCE the result of the LSP release that is requested by the PCE. In the com- mon header, the result is set to 3 (success) or 4 (failure), and the transaction ID is set to the value that is set by the LspReleaseRequest message. The contents of the LspReleaseResponse message are built using GTEP objects. The format of the LspReleaseResponse message is as fol- lows: E. Oki et al. [Page 14] E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004 ::= The code is defined as follows: Code = 1: Format error of LspSetupRequest message Code = 2: Failure on the requested LSP setup. 4.2.8. LsUpdate Message The LsUpdate message is used when the GMPLS CNTL sends the PCE the updated LSAs. In the common header, the result is set to 1, and the transaction ID is set to a non-zero value. The contents of the LsUpdate message are built using GTEP objects. The format of the LsUpdate message is as follows: ::= ... The GMPLS CNTL sends the PCE only the updated LSAs, which includes LSAs that are written or deleted in the Link State Database (LSDB), with the LsUpdate message. LSAs that are not changed in the LSDB SHOULD NOT be sent to the PCE. The deleted LSA is recognized by the MaxAge. The LSA is identified by the link state type, the link state ID, and the advertis- ing router. The CSPF overwrites the updated LSA as a new LSA in the database, if the updated LSA has the same values of the link state type, the link state ID, and the advertising router in the database. 4.2.9. LsRequest Message The LsRequest message is used when the PCE requests the GMPLS CNTL for all the LSAs that the GMPLS CNTL has. In other words, the LsRequest mes- sage is used when the PCE is booted, or the PCE's database has a problem and its database needs to be refreshed. In the common header, the result is set to 2, and the transaction ID is set to a non-zero value. The contents of the LsRequest message are built using GTEP objects. The format of the LsRequest message is as follows: ::= [] TIME_VALUE is an option and indicates an allowable waiting time from when the LsRequest message is sent to the GMPLS CNTL until when the LsResponse message is received from the GMPLS CNTL. If TIME_VALUE is E. Oki et al. [Page 15] E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004 not included, a default allowable waiting time configured by the PCE is used. If the allowable waiting time expires before the LsResponse mes- sage is received, the waiting state is released. 4.2.10. LsResponse Message The ConfigResponse message is used when the GMPLS CNTL sends the PCE its configuration of the router. In the common header, the result is set to 3 (success) or 4 (failure), and the transaction ID is set to the value that is set by the ConfigRequest message. The contents of the ConfigRe- sponse message are built using GTEP objects. The format of the ConfigRe- sponse message is as follows: ::= ... When the result is set to 3 (success), the GMPLS CNTL sends the PCE all the LSAs with the LsResponse. When the PCE received the LsResponse mes- sage, the LSA data in the PCE is cleared if any, it writes the LSAs car- ried by the LsResponse message in the PCE database. In the common header, when the result is set to 4 (failure), both LSAs are not included in the LsResponse Message and the code is defined as follows: Code = 1: Format error of LsRequest message Code = 2: There is no LSA in the GMPLS CNTL. 4.2.11. ConfigRequest Message The ConfigRequest message is used when the PCE requests the GMPLS CNTL for the configuration of the router. In the common header, the result is set to 2, and the transaction ID is set to a non-zero value. The con- tents of the ConfigRequest message are built using GTEP objects. The format of the ConfigRequest message is as follows: ::= [] TIME_VALUE is an option and indicates an allowable waiting time from when the ConfigRequest message is sent to the GMPLS CNTL until when the ConfigResponse message is received from the GMPLS CNTL. If TIME_VALUE is not included, a default allowable waiting time configured by the PCE is used. If the allowable waiting time expires before the ConfigResponse E. Oki et al. [Page 16] E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004 message is received, the waiting state is released. 4.2.12. ConfigResponse Message The ConfigResponse message is used when the GMPLS CNTL sends the PCE its configuration of the router. In the common header, the result is set to 3 (success) or 4 (failure), and the transaction ID is set to the value that is set by the ConfigRequest message. The contents of the ConfigRe- sponse message are built using GTEP objects. The format of the ConfigRe- sponse message is as follows: ::= When the result is set to 3 (success), the ConfigResponse message includes ROUTER_ID. In the common header, when the result is set to 4 (failure), ROUTER_ID is not included in the ConfigResponse Message and the code is defined as follows: Code = 1: Format error of ConfigRequest message Code = 2: Failure to get the router id. 5. GTEP Object 5.1. TIME_VALUE Class=2. The information carried in TIME_VALUE is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9 TIME_VALUE 5.1.1. C-type=1. Time Value: 32 bits. The time value indicates an allowable waiting time from when the request message is sent at the PCE/GMPLS CNTL until when E. Oki et al. [Page 17] E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004 the LspSetupRequest message is received at the PCE/GMPLS CNTL. It is expressed by millisecond. 5.2. SOURCE_IP_ADDRESS Class=3. The information carried in SOURCE_IP_ADDRESS is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IPv4 address/Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10 SOURCE_IP_ADDRESS 5.3. DESTINATION_IP_ADDRESS Class=4. The information carried in DESTINATION_IP_ADDRESS is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IPv4 address/Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11 DESTINATION_IP_ADDRESS 5.3.1. C-type=1. Destination IPv4 address: 32 bits. The destination IPv4 address is the destination of the requested route, which is an interface or a router ID. The destination IPv4 address MAY NOT be the LSP destination, when a part of the LSP route is requested. 5.4. LABEL_REQUEST Class=5. The information carried in LABEL_REQUEST is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 E. Oki et al. [Page 18] E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP Enc. Type |Switching Type | GIPD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |D| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12 LABEL_REQUEST 5.4.1. C-type=1. LABEL_REQUEST includes LSP encoding type, switching type, and informa- tion on the LSP direction, which is uni-direction or bi-direction. LSP Encoding Type: 8 bits. See [RFC3471] for a description of parame- ters. Switching Type: 8 bits. See [RFC3471] for a description of parameters. GPID: 16 bits. See [RFC3471] for a description of parameters. D: 1 bit. 0 indicates a uni-directional LSP. 1 indicates a bi-direc- tional LSP. 5.5. BANDWIDTH Class=6. The information carried in BANDWIDTH is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13 BANDWIDTH 5.5.1. C-type=1. Bandwidth: 32 bits. The bandwidth indicates the required bandwidth. Bandwidth encodings are carried in 32 bit number in IEEE floating point format (the unit is bytes per second). See [RFC3471] for a definition of values to be used for specific signal types. E. Oki et al. [Page 19] E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004 5.6. PROTECTION Class=7. The information carried in PROTECTION is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R |RT | Reserved | LSP Flags | Reserved | Link Flags| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R: Reserved RT: Route Type Figure 14 PROTECTION 5.6.1. C-type=1. Route Type: 4 bits. 0: The route of the primary LSP is requested. 1: The route of the secondary LSP is requested. 2: The routes of the primary and secondary LSPs are requested. 3: This value MUST NOT be used. A format error occurs if it is used. When Route Type=0, SECONDARY_PATH_ROUTE MUST be included in the RouteRequest message. When Route Type=1, PRIMARY_PATH_ROUTE MUST be included in the RouteRequest message. When Route Type=2, PRI- MARY_PATH_ROUTE and SECONDARY_PATH_ROUTE MUST NOT be included in the RouteRequest message. Other values is the same definition as those described in [GMPLS_RECOV- ERY_E2E]. 5.7. PATH_ROUTE Class=8. PATH_ROUTE consists of one or more Path route subobjects. The information carried in PRTH_ROUTE is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Path route subobjects ~ E. Oki et al. [Page 20] E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 15 PATH_ROUTE 5.7.1. C-type=1, PRIMARY_PATH_ROUTE. It indicates the primary route. It uses the following formats, which are IPv4 numbered subobject and unnumbered subobject. The information carried in IPv4 numbered subobject is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type | Length | IPv4 address (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address (continued) | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 16 IPv4 numbered subobject L: 1 bit. 0 indicates the strict hop. 1 indicates the loose hop. Type: 7 bits. 0x01: An IPv4 address, which is either numbered interface address or Router ID, is specified. Length: 8 bits. Length of all the IPv4 numbered subobject. It is expressed by byte. The value is always set to 8. The information carried in unnumbered subobject is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type | Length | Reserved (MUST be zero) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 17 Unnumbered subobject L: 1 bit. 0 indicates the strict hop. 1 indicates the loose hop. Type: 7 bits. 0x04: Unnumbered address. Length: 8 bits. It indicates the length of all the unnumbered subobject. E. Oki et al. [Page 21] E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004 It is expressed by byte. The value is always set to 12. 5.7.2. C-type=2, SECONDARY_PATH_ROUTE. It indicates the secondary route. It uses the same format as PRI- MARY_PATH_ROUTE. 5.8. LSP_TUNNEL_IF_ID Class=9. 5.8.1. C-type=1, INGRESS_LSP_TUNNEL_IF_ID. It indicates the TUNNEL_IF_ID of the setup LSP at the ingress. The information carried in LSP_TUNNEL_IF_ID is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 18 LSP_TUNNEL_IF_ID The format is based on TUNNEL_IF_ID described in [RFC3477]. See [RFC3477] for a description of parameters. 5.8.2. C-type=2, EGRESS_LSP_TUNNEL_IF_ID. It indicates the TUNNEL_IF_ID of the setup LSP at the egress. It uses the same format as INGRESS_LSP_TUNNEL_IF_ID. 5.9. LSA Class=10. The information carried in LSA is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E. Oki et al. [Page 22] E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004 | Area ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | LS type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ | LSA contents | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 19 LSA 5.9.1. C-type=1. LSA includes all the LSA types. Area ID: 32 bits. It indicates the area ID of the LSA. Other values is the same definition as those described in [RFC2328][RFC2370], except for the LS checksum and the length. The PCE ignores the LS checksum. It indicates the length including 20 bytes LSA header, except for the area ID, and the LSA contents. It is expressed by byte. 5.10. ROUTER_ID Class=11. The information carried in ROUTER_ID is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 20 ROUTER_ID E. Oki et al. [Page 23] E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004 5.10.1. C-type=1. Router ID: 32 bits. It indicates the route ID. 6. 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 stan- dard. Please address the information to the IETF at ietf-ipr@ietf.org. 7. 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. 8. References [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. [RFC2370] R. Coltun, "The OSPF Opaque LSA Option," RFC 2370. [RFC3630] D. Katz et al., "Traffic Engineering (TE) Extensions to OSPF E. Oki et al. [Page 24] E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004 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-09.txt, Dec. 2002. (working in progress) [GMPLS_RECOVERY_E2E] J.P. Lang et al., "RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery," IETF draft, draft-ietf-ccamp-gmpls- recovery-e2e-signaling-00.txt, Mar. 2004. (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) 9. Authors' Address Eiji Oki NTT Midori 3-9-11 Musashino, Tokyo 180-8585, Japan Email: oki.eiji@lab.ntt.co.jp Daisaku Shimazaki NTT Midori 3-9-11 Musashino, Tokyo 180-8585, Japan Email: shimazaki.daisaku@lab.ntt.co.jp Kohei Shiomoto NTT 3-9-11 Midori-cho, Musashino-shi, Tokyo 180-8585, Japan Email: shiomoto.kohei@lab.ntt.co.jp E. Oki et al. [Page 25] E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004 E. Oki et al. [Page 26]