CCAMP Working Group Eiji Oki Internet Draft Daisaku Shimazaki Expiration Date: October 2004 Kohei Shiomoto April 2004 Generalized Traffic Engineering Protocol draft-oki-ccamp-gtep-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt 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). All Rights Reserved. Abstract This draft describes a generalized traffic engineering protocol (GTEP). GTEP is a protocol that communicates between a Constrained Shortest Path First (CSPF) engine 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. The CSPF engine provides a function of traffic engineering, which calculates LSP routes and judges whether a new lower-layer LSP should be established. E. Oki et al. [Page 1] E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004 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]. 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 envi- ronments, traffic engineering becomes more complicated, compared 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 to judge 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 realis- tic that the LSP route calculation engine, or constrained shortest path first (CSPF) engine, that performs multi-region traffic engineering (MRTE) with several constraints is implemented into all the node. More- over, judgements such as whether new LSPs SHOULD be established, or existing LSPs SHOULD be used depends on network providers' traffic-engi- neering policy. Network providers want to have own traffic engineering engine. From vendors' points of view, it is not desirable to implement the CSPF engine that considers all the requirements from network providers. A complicated CSPF engine may also cause the node to degrade its processing capablity. Therefore, it is reasonable to separate the CSPF engine from a GMPLS controller that handles GMPLS protocols. This draft describes a generalized traffic engineering protocol (GTEP). GTEP is a protocol that communicates between the CSPF engine engine and the GMPLS controller (GMPLS CNTL). 2. GTEP Overview E. Oki et al. [Page 2] E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004 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| | +-----------+ | +------+ | |CSPF engine+---------||---------+ | +-----------+ GTEP | +----+ +------+ | | |LSDB+--+ OSPF | | | +----+ |module| | | +------+ | +------------------+ GMPLS CNTL Figure 1 Communication between CSPF engine and GMPLS CNTL with GTEP. GTEP is a protocol that communicates between an CSPF engine and a GMPLS CNTL. A GMPLS CNTL is a controller that handles GMPLS and MPLS proto- cols and controls a GMPLS node. The GMPLS CNTL handles GMPLS protocols such as signaling and routing protocols. Figure 1 depicts the GMLS CNTL structure that includes a RSVP module and a OSPF moudle with a Link State Database (LSDB) The CSPF engine provides a function of traffic engineering, which calcu- lates LSP routes and judges whether a new lower-layer LSP SHOULD be established. Applicability of CSPF Engine is as follows. For single-layer networks, the CSPF engine provides LSP routes considering several constraints. For multi-region networks, a function of multi-region traffic engineer- ing, which calculates LSP routes and judges whether a new lower-layer LSP SHOULD be established. The detail functions of the GMPLS CNTL and the CSPF engine based on GTEP are descrbied in the following subsections. Note that functions that are related to the GTEP procedures getting the information on LSDB are optional. This is because several alternatives to have topology data in the CSPF engine can be considered. E. Oki et al. [Page 3] E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004 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 a CSPF engine to give the LSP route to it. The CSPF engine calculates the LSP route and gives it to the GMPLS CNTL. The GMPLS CNTL establishes the LSP according to the route suggested by the CSPF engine. The CSPF engine requires the GMPLS CNTL to setup a lower-layer LSP if it is necessary. In this case, the GMPLS CNTL tries to setup the lower- layer LSP and returns the result whether the LSP setup succeeds to the CSPF engine. When the LSP setup succeeds, the result includes LSP_TUN- NEL_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 CSPF engine. When the GMPLS CNTL is requested to give the LSDB information, it sends the latest LSDB infor- mation to the CSPF engine. 2.3. CSPF Engine Function CSPF engine gives the GMPLS CNTL an LSP route when the LSP route is requested by the GMPLS CNTL. The CSPF engine calculates the LSP route by using Traffic Engineering Database (TED). TED in the CSPF engine is cre- ated by using the information of the LSDB in the GMPLS CNTL. The CSPF engine requires the GMPLS CNTL to setup a lower-layer LSP if it is necessary. In this case, the GMPLS CNTL tries to setup the lower- layer LSP and returns the result whether the LSP setup succeeds to the CSPF engine. When the LSP setup succeeds, the result includes LSP_TUN- NEL_IF_ID for a FA LSP. The CSPF engine 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 CSPF engine. According to the LSDB update, the CSPF engine also updates the TED. When the CSPF engine is booted, it requests the information of LSDB to the GMPLS CNTL. The GMPLS CNTL sends the information of LSDB to the CSPF engine. Then, the CSPF engine creates TED. 3. GTEP Procedure In this section, typical sequences are desribed. E. Oki et al. [Page 4] E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004 3.1. CSPF Engine Boot Sequence CSPF engine GMPLS CNTL | | | ConfigRequest Message | |-------------------------------->| | | | ConfigResponse Message | |<--------------------------------| | | | LsRequest Message | |-------------------------------->| | | | LsResponse Message | |<--------------------------------| | | Figure 2 CSPF engine boot sequence. Step 1. The CSPF engine is booted. Step 2. The CSPF engine sends ConfigRequest Message to the GMPLS CNTL to request configuration in the GMPLS CNTL. Step 3. The GMPLS CNTL sends ConfigResponse Message to the CSPF engine to give the configuration. Step 4. The CSPF engine 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 CSPF engine to give the LSDB information. Note that steps 1 and 2 may be omitted when the CSPF engine wants to synchronize only the LSDB information with the GMPLS CNTL. 3.2. Link-state update sequence CSPF engine GMPLS CNTL | | | LsUpdate Message | |<--------------------------------| | | Figure 3 Link-state update sequence. Step 1. The GMPLS CNTL sends LsUpdate Message to CSPF engine to give the updated LSAs, which includes LSAs that are written or deleted in the LSDB, with the LsUpdate message. LSAs that are not changed in the LSDB E. Oki et al. [Page 5] E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004 SHOULD NOT be sent to the CSPF engine. 3.3. LSP Setup Sequence for Single Layer Case CSPF engine GMPLS CNTL | | | RouteRequest Message | |<--------------------------------| | | | RouteResponse Message | |-------------------------------->| | | Figure 4 LSP setup sequence for single layer case. Step 1. The GMPLS CNTL is requested to setup an LSP. Step 2. The GMPLS CNTL sends RouteRequest Message to the CSPF engine to ask it to give the LSP route. Request Message. Step 3. The CSPF engine sends RouteResponse Message to the GMPLS CNTL to give the LSP route. If the result is "success", RouteResponse Message includes the route. The specified route is formatted as Explicit Route Object that is carried in a Path message. If the result is "failure", RouteResponse Message includes an error code that indicates why the result is "failure", and optically includes suggested routes but does not competely satisfy the constraints and suggested alternative con- straints that enable to find a route [MPLS-COMP]. In MPLS networks, [MPLS-COMP] describes examples of alternative constraints such as band- width and protection type. In GMPLS networks, alternative constraints such as switching type, encoding type, GPID, and SRLG are extended. 3.4. LSP Setup Sequence for Two Layer Case CSPF engine GMPLS CNTL | | | RouteRequest Message | |<--------------------------------| | | | LspSetupRequest Message* | |-------------------------------->| | | | LspSetupResponse Message* | |<--------------------------------| | | | RouteResponse Message | E. Oki et al. [Page 6] E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004 |-------------------------------->| | | *The LspSetupRequest/LspSetupResponse Messages appear only when the lower-layer LSP needs to be established. Figure 5 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 MAY be 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. Otherwise, go to Step 7. 1. Explicit Route is not specified. 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 satisfies constraints such as bandwidth between the node and the next hop node. Step 3. The GMPLS CNTL sends RouteRequest Message to the CSPF engine to request a route of the higher-layer LSP. Step 4. The CSPF engine requires the GMPLS CNTL to setup a lower-layer LSP if it is necessary. Otherwise, go to Step 6. The GMPLS CNTL judges that it is necessary to establish a new lower-layer LSP in either of the following cases. 1. There is no TE-link that satisfies constraints such as bandwidth between the node and the next hop node, or 2. GMPLS CNTL finds a shorter route with the new lower-layer LSP than the shortest route on the existing low-layer-LSP topology. Step 5. The GMPLS CNTL tries to setup the lower-layer LSP and returns the result whether the LSP setup succeeds to the CSPF engine. When the LSP setup succeeds, the result includes LSP_TUNNEL_IF_ID for the FA LSP. Step 6. The CSPF engine sends RouteResponse Message that specifies the route of the higher-layer LSP to the GMPLS CNTL if the result is "suc- cess". The specified route is formatted as Explicit Route Object that is carried in a Path message. The specified route is formatted as Explicit Route Object that is carried in a Path message. If the result is "failure", RouteResponse Message includes an error code that indi- cates why the result is "failure", and optically includes suggested routes but does not competely satisfy the constraints and suggested alternative constraints that enable to find a route [MPLS-COMP]. In MPLS networks, [MPLS-COMP] describes examples of alternative constraints such as bandwidth and protection type. In GMPLS networks, alternative con- straints such as switching type, encoding type, GPID, and SRLG are E. Oki et al. [Page 7] E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004 extended. 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. 4. GTEP Message 4.1. Common Header and Common Trailer In addition to the TPC 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 6 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 5 = LspSetupResponse Message 6 = LsUpdate Message 7 = LsRequest Message 8 = LsResponse Message 9 = ConfigRequest Message 10 = ConfigResponse Message E. Oki et al. [Page 8] E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004 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 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. E. Oki et al. [Page 9] E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004 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 7 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 CSPF engine 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: ::= [] [] [] TIME_VALUE is an option and indicates an allowable waiting time from when the RouteRequest message is sent to the CSPF engine until when the RouteResponse message is received from the CSPF engine. 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. E. Oki et al. [Page 10] E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004 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 CSPF engine 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 CSPF engine by setting DESTINA- TION_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 CSPF engine 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 CSPF engine for the route of the secondary LSP. 4.2.2. RouteResponse Message The RouteResponse message is used when the GMPLS CNTL gives the CSPF engine an LSP route that is requested by the CSPF engine. 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 RouteRequest message. The contents of the RouteResponse message are built using GTEP objects. The format of the RouteResponse message is as follows: ::= [] [] 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: E. Oki et al. [Page 11] E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004 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 CSPF engine as the RouteRequest message. When the CSPF engine 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 CSPF engine 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 follows: ::= [] [] 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 MPLS engine is used. If the allowable waiting time expires before the LspSetupResponse message is received, the waiting state is released. DESTINATION_IP_ADDRESS indicates a destination IP address of the LSP that is requested to be setup. The node that is connected to the GMPLS node is a source node. E. Oki et al. [Page 12] E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004 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 CSPF engine 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 CSPF engine the result of the LSP setup that is requested by the CSPF engine. 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 LspSe- tupRequest message. 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 Code = 2: Failure on the requested LSP setup. 4.2.6. LsUpdate Message The LsUpdate message is used when the GMPLS CNTL sends the CSPF engine 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: E. Oki et al. [Page 13] E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004 ::= ... The GMPLS CNTL sends the CSPF engine 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 CSPF engine. The deleted LSA is recog- nized by the MaxAge. The LSA is identified by the link state type, the link state ID, and the advertising 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 advertis- ing router in the database. 4.2.7. LsRequest Message The LsRequest message is used when the CSPF engine requests the GMPLS CNTL for all the LSAs that the GMPLS CNTL has. In other words, the LsRe- quest message is used when the CSPF engine is booted, or the CSPF engine'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 not included, a default allowable waiting time configured by the MPLS engine is used. If the allowable waiting time expires before the LsRe- sponse message is received, the waiting state is released. 4.2.8. LsResponse Message The ConfigResponse message is used when the GMPLS CNTL sends the CSPF engine 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 ConfigResponse message are built using GTEP objects. The format of the ConfigResponse message is as follows: ::= E. Oki et al. [Page 14] E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004 ... When the result is set to 3 (success), the GMPLS CNTL sends the CSPF engine all the LSAs with the LsResponse. When the CSPF engine received the LsResponse message, the LSA data in the CSPF engine is cleared if any, it writes the LSAs carried by the LsResponse message in the CSPF- engine 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 LspRequest message Code = 2: There is no LSA in the GMPLS CNTL. 4.2.9. ConfigRequest Message The ConfigRequest message is used when the CSPF engine 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 contents 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 MPLS engine is used. If the allowable waiting time expires before the Confi- gResponse message is received, the waiting state is released. 4.2.10. ConfigResponse Message The ConfigResponse message is used when the GMPLS CNTL sends the CSPF engine 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 ConfigResponse message are built using GTEP objects. The format of the ConfigResponse message is as follows: ::= E. Oki et al. [Page 15] E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004 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 8 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 CSPF engine/GMPLS CNTL until when the LspSetupRequest message is received at the CSPF engine/GMPLS CNTL. It is expressed by millisecond. 5.2. DESTINATION_IP_ADDRESS Class=3. 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 | E. Oki et al. [Page 16] E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9 DESTINATION_IP_ADDRESS 5.2.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.3. LABEL_REQUEST Class=4. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP Enc. Type |Switching Type | Reserved |D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10 LABEL_REQUEST 5.3.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. D: 1 bit. 0 indicates a uni-directional LSP. 1 indicates a bi-direc- tional LSP. 5.4. BANDWIDTH Class=5. 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 E. Oki et al. [Page 17] E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11 BANDWIDTH 5.4.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. 5.5. PROTECTION Class=6. 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 12 PROTECTION 5.5.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]. E. Oki et al. [Page 18] E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004 5.6. PATH_ROUTE Class=7. 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 ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13 PATH_ROUTE 5.6.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 14 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E. Oki et al. [Page 19] E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004 | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 15 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. It is expressed by byte. The value is always set to 12. 5.6.2. C-type=2, SECONDARY_PATH_ROUTE. It indicates the secondary route. It uses the same format as PRI- MARY_PATH_ROUTE. 5.7. LSP_TUNNEL_IF_ID Class=10. 5.7.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 16 LSP_TUNNEL_IF_ID The format is based on TUNNEL_IF_ID described in [RFC3477]. See [RFC3477] for a description of parameters. E. Oki et al. [Page 20] E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004 5.7.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.8. LSA Class=11. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Area ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | LS type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ | LSA contents | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 17 LSA 5.8.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 CSPF engine 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. E. Oki et al. [Page 21] E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004 5.9. ROUTER_ID Class=12. 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 18 ROUTER_ID 5.9.1. C-type=1. Router ID: 32 bits. It indicates the route ID. 6. 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 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] D. Papadimitriou et al., "Generalized MPLS Architecture for Multi- E. Oki et al. [Page 22] E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004 Region Networks, draft-vigoureux-shiomoto-ccamp-gmpls-mrn-04.txt, Feb. 2004. (working 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) [MPLS-COMP] JP Vasseur et al., "RSVP Path computation request and reply messages," IETF draft, draft-vasseur-mpls-computation-rsvp-03, June 2002. 7. 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 23]