CCAMP Working Group Dean Cheng (Polaris Networks) Internet Draft Expiration Date: December 2001 June 2001 GMPLS Extensions for Dynamic Trunking draft-cheng-gmpls-dynamic-trunking-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." To view the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow Directory, see http://www.ietf.org/shadow.html. Abstract Currently the GMPLS signaling requires to include a "LSP Encoding Type" in the Generalized Label Request ([GMPLS-SIG]), which indicates the encoding of the LSP being requested. Upon receiving a RSVP PATH message or CR-LDP REQUEST message that contains a Generalized Label Request, a LSR must verify if the receiving and transmitting interface can support the LSP. In particular on the transmitting side, the node either finds an interface that has the same switching class, among other requirements, or it may use a FA-LSP, i.e., another class of switching. In a GMPLS network which provides multi-services, it is not efficient nor scalable to statically configure each interface with a given siwtching class. Further more, the primary benefit of FA-LSP is for scaling the MPLS TE as a whole but it may be too heavy a mechanism to solve switching capability problem in a local context. This document describes a mechanism to dynamically create an interface on the transmitting side of a LSR with the desirable switching class if not already exists, upon receiving a LSP setup request message that contains a Generalized Label Request. We call such a feature as dynamic trunking in the rest of the document. Table of Contents 1.0 Introduction ....................................................... 1 2.0 Routing Enhancements ............................................... 2 2.1 Dynamic Trunk and its Advertisement ............................ 2 2.1.1 Traffic Engineering Parameters ........................... 2 2.1.1.1 Link Type (OSPF Only) ........................... 2 2.1.1.2 Link ID (OSPF Only) ............................. 2 2.1.1.3 Local and Remote Interface IP Addresses ......... 2 2.1.1.4 Outgoing and Incoming Interface Identifiers ..... 3 2.1.1.5 Traffic Engineering Metric ...................... 3 2.1.1.6 Maximum Bandwidth ............................... 3 2.1.1.7 Unreserved Bandwidth ............................ 3 2.1.1.8 Resource Class/Color ............................ 3 2.1.1.9 Link Multiplex Capability ....................... 3 2.1.1.10 Maximum LSP Bandwidth ........................... 3 2.1.1.11 Link Protection Type ............................ 3 2.1.1.12 Link Descriptor ................................. 3 2.1.1.13 Shared Risk Link Group (SRLG) ................... 4 2.1.1.14 Dynamic Trunk Multiplex Capability (DTMC) ....... 4 2.1.1.14.1 OSPF DTMC sub-TLV .................... 4 2.1.1.14.2 IS-IS DTMC sub-TLV ................... 4 2.1.2 Advertisement for Dynamic Trunk .......................... 4 2.2 Dynamic TE Link and its Advertisement .......................... 5 2.3 Dynamic Trunking and Link Bundling ............................. 5 2.4 LSP Path Selection Consideration ............................... 5 3.0 Signaling Enhancements ............................................. 6 3.1 Restrictions ................................................... 6 3.2 Additional Handling ............................................ 7 4.0 LMP Enhancements ................................................... 7 4.1 Additional flag to the LMP Capability TLV ...................... 8 4.2 Additional LMP Message Types ................................... 8 4.3 Create Dynamic Trunk ........................................... 8 4.3.1 CreateDynamicTrunk Message (MsgType = 22) ................ 8 4.3.2 CreateDynamicTrunkAck Message (MsgType = 23) ............. 9 4.3.3 CreateDynamicTrunkNack Message (MsgType = 24) ............ 10 4.4 Add Link Messages .............................................. 10 4.4.1 AddLink Message (MsgType = 25) ........................... 10 4.4.1.1 TE Link TLV ...................................... 11 4.4.1.2 Data Link TLV .................................... 11 4.4.1.3 Data Link Creation Sub-TLV ....................... 11 4.4.2 AddLinkAck Message (MsgType = 26) ........................ 11 4.4.3 AddLinkNack Message (MsgType = 27) ....................... 11 4.5 Delete Link Messages ........................................... 12 4.5.1 DeleteLink Message (MsgType = 28) ........................ 12 4.5.1.1 TE Link TLV ...................................... 12 4.5.1.2 Data Link TLV .................................... 13 4.5.2 DeleteLinkAck Message (MsgType = 29) ..................... 13 4.5.3 DeleteLinkNack Message (MsgType = 30) .................... 13 5.0 Security Considerations ............................................ 13 6.0 References ......................................................... 14 7.0 Author's Addresses ................................................. 14 1.0 Introduction In general, a TE link between a pair of physically adjacent LSRs needs to be configured with a given switching multiplex capability type assigned before it can be used to carry LSPs with the associated classes. The LMP ([GMPLS-LMP]) may be used to manage all the TE links between two neighboring LSRs. A TE link with a particular switching class that inter-connect two neighboring LSRs may also be created dynamically driven by the need, i.e., when a LSP setup message arrives. When such a TE link is created, its switching class is set to be the same as that of the LSP. The setting of other characteristics of the TE link is a local policy issue, but at the end of this, the LSP must be able to ride on the TE link that just created. After the dynamic TE link being created, it must be treated as a normal TE link that is created by static configuration, including link bundling, managed by LMP, advertised by IGP, etc. In particular, a TE link dynamically created shall be used to carry other LSPs with the associated switching class as described in the [GMPLS-HIER]. When a dynamically created TE link no longer carries any LSP, it may be deleted and the associated resources released at the two neighbor LSRs. This procedure is referred as garbage collection. A timer may be used to trigger the garbage collection action once the TE link no longer carries LSP. The creation and deletion of a dynamic TE link shall be accomplished by the LMP with additional mechanisms. For a LSR that is capable of creating dynamic TE link, it may advertise such a capability using IGP. This can be achieved by adding additional mechanisms in the GMPLS-capable IGP, i.e. the OSPF ([GMPLS-OSPF]) and ISIS ([GMPLS-ISIS]). The advertisement includes the raw bandwidth that is available to be used for dynamic trunking purpose, along with the set of switching multiplex capabilities that the LSR is capable of, or willing to be associating with dynamic TE links. We refer the object that associated with such an advertisement as "dynamic trunk". A dynamic trunk is associated with a given set of bandwidth like a regular TE link, but is incapable of carrying LSP directly. One or more TE links may be created dyanmically using the resources that associated with a single dynamic trunk. When a dynamic TE link is created or deleted within a dynamic trunk, the advertisement for the dynamic trunk may be updated by the IGP. A LSR, when performing path computation, may use conventional TE links, forwading adjacencies (FA-LSP), and now also dynamic trunks. [Page 1] If a dynamic trunk is chosen, it must be noted in the LSP setup request for the associated hop so that a dynamic TE link can be created when the LSP setup request travels to the node that advertising the dynamic trunk. 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 [RFC2119]. 2.0 Routing Enhancements In this section we describe enhancements to the OSPF and IS-IS that required to support the dynamic trunking feature, including the advertisement for the dynamic trunk (Section 2.1), the advertisement for the dynamic TE link (Section 2.2), and the path computation that includes dynamic trunks (Section 2.4). 2.1 Dynamic Trunk and its Advertisement In addition to the advertisements for the regular TE links as described in the GMPLS IGPs ([GMPLS-OSPF] and [GMPLS-ISIS]), a dynamic trunking capable LSR may also advertise the dynamic trunking capability. Each dynamic trunking advertisement is associated with a given pair of adjacent LSRs. For a given pair of adjacent LSRs, the number of dynamic trunking advertisements is determined by the local policy. 2.1.1 Traffic Engineering Parameters The format of advertisement for a dynamic trunk is similar to that of a regular TE link as described in the following sections. 2.1.1.1 Link Type (OSPF Only) The Link Type of a dynamic trunk is set to "point-to-point". 2.1.1.2 Link ID (OSPF Only) The Link ID is set to the Router ID of the adjacent LSR. 2.1.1.3 Local and Remote Interface IP Addresses A dynamic trunk may be either a numbered or unnumbered. If is numbered, the Local Interface IP Address is set to OSPF local interface IP address or IS-IS IPv4 interface address that associated with the dynamic trunk. The remote Interface IP address is set to OSPF remote interface IP address or IS-IS IPv4 neighbor address that associated with the dynamic trunk. The association between a dynamic trunk and the set of IP addresses is a local matter. For a unnumbered dynamic trunk, these two fields must be set to zero. [Page 2] 2.1.1.4 Outgoing and Incoming Interface Identifiers A dynamic trunk may be either a numbered or unnumbered. If is unnumbered, there must be a 32-bit number on each LSR that uniquely identify a dynamic trunk on a LSR, and this number is used as the value of Outgoing Interface Identifier. Via LMP, the Outgoing Interface Identifier on the other end of the dynamic trunk is leanred and is used as the value of Incoming Interface Identifier. For a numbered dynamic trunk, these two fields must be set to zero. 2.1.1.5 Traffic Engineering Metric By default, the TE metric on a dynamic trunk is set to a very large value so that it will only be possibly used as a last resort. The actual setting for the TE metric is a local matter. 2.1.1.6 Maximum Bandwidth The Maximum Bandwidth of a dynamic trunk is set via configuration, which indicates the capacity of the raw bandwidth that may be used to create dynamic TE links within. This value is set to the same as the Maximum LSP bandwidth at the lowest priority (see the Section 2.1.1.10). 2.1.1.7 Unreserved Bandwidth By default, the Unreserved Bandwidth of all priority levels are set to the Maximum Bandwidth. 2.1.1.8 Resource Class/Color By default, a dynamic trunk has no color, but may be changed via configuration. 2.1.1.9 Link Multiplex Capability For the advertisement of a dynamic trunk, this is replaced by the Dynamic Trunk Multiplex Capability (DTMC), see the Section 2.1.1.14. 2.1.1.10 Maximum LSP Bandwidth The Maximum LSP Bandwidth of each priority is set via configuration, and each of them indicates the capacity of the raw bandwidth that may be used to create dynamic TE links within. 2.1.1.11 Link Protection Type The protection type of a dynamic trunk is set via configuration. 2.1.1.12 Link Descriptor The Link Descriptor is not included in the advertisement for a dynamic trunk. [Page 3] 2.1.1.13 Shared Risk Link Group (SRLG) The SRLG type of a dynamic trunk is set via configuration. 2.1.1.14 Dynamic Trunk Multiplex Capability (DTMC) This is a new sub-TLV added to the OSPF and IS-IS to support the dynamic trunking enhancement and is a sub-TLV of the Link TLV. The value of the DTMC includes a two-octet which is a bit vector as defined as the following: Bits Multiplex Capabilities ----- ---------------------- 0x8000 Packet-Switch Capable-1 (PSC-1) 0x4000 Packet-Switch Capable-1 (PSC-2) 0x2000 Packet-Switch Capable-1 (PSC-3) 0x1000 Packet-Switch Capable-1 (PSC-4) 0x0800 Layer-2 Switch Capable (L2SC) 0x0400 Time-Division-Multiplex capable (TDM) 0x0200 Lambda-Switch Capable (LSC) 0x0100 Fiber-Switch Capable (FSC) Rest bits Reserved A bit in the value field, if set, indicates that one or more TE links may be dynamically created with that switching multiplex capability, and with the bandwidth allocated from the dyanmic trunk that advertised. Note multiple bits may be set for a dynamic trunk. 2.1.1.14.1 OSPF DTMC sub-TLV The code point of the OSPF Dyanmic Trunk Multiplex Capability sub-TLV is as the 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 17 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multiplex Capability | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Length field is set to 4, and the Multiplex Capability contains a bit vector as described as in the Section 2.1.1.14 above. 2.1.1.14.2 IS-IS DTMC sub-TLV The code point of the IS-IS Dyanmic Trunk Multiplex Capability sub-TLV is as the follows: Type - 21 Length - two octets. Value - two octets as described as in the Section 4.1.1.14. [Page 4] 2.1.2 Advertisement for Dynamic Trunk A dynamic trunk may only be advertised by a dynamic trunking capable LSR. A dynamic trunk is always bi-directional in the sense that any TE link dynamically created within can carry LSP that is either bi-directional or uni-directional. Therefore, the two adjacent LSRs must all advertise a dynamic trunk in their associated context before that dynamic trunk can be used to create TE links. When a TE link is created or deleted using the bandwidth within a dynamic trunk, the advertisement for the dynamic trunk may be refreshed. The initial bandwidth assigned to a dynamic trunk and the policy to re-advertising are both local matter. 2.2 Dynamic TE Link and its Advertisement A dynamic TE link is used in the same context of routing and signaling as a regular TE link. The set of TE parameters is set according to the specification as described in the [GMPLS-OSPF] and [GMPLS-ISIS], for OSPF and IS-IS, respectively, used for the IGP. There are some considerations in regarding the dynamic TE link as stated as follows: 1) It is recommended that a dynamic TE link is always advertised as a unnumbered link. 2) The Incoming Interface Identifier of a TE link is obtained via LMP. 3) The setting of the Maximum LSP Bandwidth is determined by the local policy, but must be at least as big as the LSP that induced the dynamic TE link. 4) The Link Multiplex Capability is set to the one that associated with the LSP Encoding Type contained in the GMPLS signaling request. 5) Some of the TE parameters such as TE metric, Shared Risk Link Group, Resource Class/Color, Link Protection Type, etc., may be inherited from the associated dynamic trunk where the bandwidth is allocated from. They may be changed via configuration just like a regular TE link. 2.3 Dynamic Trunking and Link Bundling A dynamic trunk is always advertised explicitly. The link bundling mechanism as described in the ([GMPLS-BUNDLE]) must not be applied on a dynamic trunk, but may be applied to a dynamic TE link. [Page 5] 2.4 LSP Path Selection Consideration A dynamic trunk is advertised by the two adjacent LSRs just like a regular TE link. The dynamic trunk may be used in the LSP path selection procedure in the same context as a regular TE link except: 1) A dynamic trunk may only be considered when there is no other exsting TE links available between two adjacent nodes. This is in the consideration of conserving the dynamic trunking resources in the network. 2) If a dynamic trunk is chosen and included in the Explicit Route Object (ERO), the proper references must be included so that the local node understands a dynamic TE link needs to be created. The proper references are either IP addresses on a numbered dynamic trunk, or interface identifiers on a unnumbered link. 3) Zero, one or more dynamic trunks may be included in a single ERO, with each, if presented, corresponds to a pair of adjacent LSRs that the LSP as requested traversing. 3.0 Signaling Enhancements In this section we describe enhancements to the GMPLS signaling protocols that required to support the dynamic trunking. The dynamic trunk is advertised by IGP, and may be chosen by the ingress LSR that includes it in the ER object just like a regular TE link. Therefore there is no need for a special indication in the GMPLS signaling protocols when a dyanmic trunk is included in the ER object, nor any code point changes required. 3.1 Restrictions There are three restrictions for the use of the dynamic trunk in the MPLS signaling request messages as follows: 1) The inclusion of any dynamic trunk in the GMPLS signaling setup request message is allowed only if the Generalized Label Request Object is included ([GMPLS-SIG], [GMPLS-SIG], [GMPLS-RSVP]). The Generalized Label Request Object contains the LSP Encoding type that is needed to determine the multiplex capability of the TE link that is going to be dynamically created using the bandwidth on the dynamic trunk. 2) The inclusion of a dynamic trunk in the GMPLS signaling setup request message must be associated with a strict hop, but not a loose hop. [Page 6] 3) The inclusion of a dynamic trunk in the GMPLS signaling setup request message can only be associated with a numbered link or an unnumbered link, but not an abstract node. For RSVP, a dynamic trunk is specified in one of the three possible way: 1) IPv4 prefix ([RSVP-TE]) 2) IPv6 prefix ([RSVP-TE]) 3) unnumbered link ([UNNUM-RSVP]) For CR-LDP, a dynamic trunk is specified in one of the three possible way: 1) IPv4 prefix ([CR-LDP]) 2) IPv6 prefix ([CR-LDP]) 3) unnumbered link ([UNNUM-CRLDP]) 3.2 Additional Handling When a LSR receives a LSP setup request that contains an ER object, the processing rules as specified in the associated signaling specifications are performed as usual. In addition, if the next hop is associated with a dynamic trunk that is still valid as the LSR previously advertised, the LSR needs to create a TE link that inter-connects itself and the next hop LSR, with the set of TE parameters as described in the Section 2.2. Onece the dynamic creation of the TE link is successful, the original call setup request can then be forwarded to the next hop as usual. The creation of the dynamic TE link can be achieved by the LMP with enhancements as described in the Section 4.0. This document does not preclude other mechanisms however. 4.0 LMP Enhancements 4.1 Additional flag to the LMP Capability TLV A new flag is added to the LMP capability TLV as follows: 0x04 Dynamic Trunking Procedure Refer to the Section 9.4.1.2 of [GMPLS-LMP] for the existing LMP capability flags. The dynamic trunking capability must be a negotiable (N=1) parameter, and only when both adjacent nodes are capable of performing this extended LMP procedure, the IGP can then advertise the dynamic trunk as described in the Section 4.1. If the negotiation on this procedure is successful, the following new messages may be exchanged between the two nodes: [Page 7] CreateDynamicTrunk (Section 4.3.1) CreateDynamicTrunkAck (Section 4.3.2) CreateDynamicTrunkNack (Section 4.3.3) AddLink (Section 4.4.1) AddLinkAck (Section 4.4.2) AddLinkNack (Section 4.4.3) DeleteLink (Section 4.5.1) DeleteLinkAck (Section 4.5.2) DeleteLinkNack (Section 4.5.3) 4.2 Additional LMP Message Types The following new message types are added to the LMP. 22 = CreateDynamicTrunk 23 = CreateDynamicTrunkAck 24 = CreateDynamicTrunkNack 25 = AddLink 26 = AddLinkAck 27 = AddLinkNack 28 = DeleteLink 29 = DeleteLinkAck 30 = DeleteLinkNack For the definition of existing LMP message types, refer to the Section 9.1 of the [GMPLS-LMP]. 4.3 Create Dynamic Trunk 4.3.1 CreateDynamicTrunk Message (MsgType = 22) A CreateDynamicTrunk is sent over the control channel and its purpose is to make a suggestion to the neighboring peer to create a dynamic trunk. The format of the CreateDynamicTrunk message is as follows: ::= The CreateDynamicTrunk object has the following format: [Page 8] 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MessageId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Dynamic Trunk Id / Local Interface IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Dynamic Trunk Id / Remote Interface IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BitRate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DTMC | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MessageId: 32 bits When combined with the CCId, the MessageId field uniquely identifies a message. This value is incremented and only decreases when the value wraps. This is used for message acknowledgement in the CreateDynamicTrunkAck and CreateDynamicTrunkNack messages. Local Dynamic Trunk Id or Local Interface IP Address : 32 bits This is either the Local Dynamic Trunk Id or the Local Dynamic Trunk IP Address, depending on the flag setting. Remote Dynamic Trunk Id or Remote Interface IP Address : 32 bits This is either the Remote Dynamic Trunk Id or the Remote Dynamic Trunk IP Address, depending on the flag setting. If the value set to 0, the local node has no knowledge of the remote node. BitRate: 32 bits This is the bit rate in bytes per second which specifies the available bandwidth of the dynamic trunk. DTMC: 16 bits This is the flags for Dynamic Trunk Multiplex Capability, refer to the Section 4.1.1.14. Flags: 16 bits There is only one flag currently defined: 0x0001 Link type If this bit is set, the dynamic trunk is numbered, and otherwise is unnumbered. [Page 9] 4.3.2 CreateDynamicTrunkAck Message (MsgType = 23) A CreateDynamicTrunkAck is sent over the control channel and its purpose is to acknowledge the creation of a dynamic trunk between the two nodes. The format of the CreateDynamicTrunkAck message is as follows: ::= The CreateDynamicTrunkAck object has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MessageId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.3.3 CreateDynamicTrunkNack Message (MsgType = 24) A CreateDynamicTrunkNack is sent over the control channel and its purpose is to deny the creation of a dynamic trunk between the two nodes. The format of the CreateDynamicTrunkNack message is as follows: ::= The CreateDynamicTrunkNack object has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MessageId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.4 Add Link Messages 4.4.1 AddLink Message (MsgType = 25) The AddLink messsage is used to add a data link dynamically with bandwidth allocated from a dynamic trunk. A data link added may either be a port or a component link, and may be included within an existing or a new TE link between the two nodes. [Page 10] The format of the AddLink message is as follows: ::= The AddLink object has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MessageId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (AddLink TLVs) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MessageId: 32 bits When combined with the CCId, the MessageId field uniquely identifies a message. This value is incremented and only decreases when the value wraps. This is used for message acknowledgement in the AddLinkAck and AddLinkNack messages. 4.4.1.1 TE Link TLV The definition and format of the TE link TLV are defined in the Section 9.7.1.1 of [GMPLS-LMP]. 4.4.1.2 Data Link TLV The definition and format of the data link TLV are defined in the Section 9.7.1.2 of [GMPLS-LMP]. 4.4.1.3 Data Link Creation Sub-TLV The Data Link Creation Sub-TLV is TLV Type=7 and is defined 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| 7 | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BitRate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ BitRate: 32 bits This is the bit rate in bytes per second which specifies the initial bandwidth of the data link. 4.4.2 AddLinkAck Message (MsgType = 26) The AddLinkAck message is sent over the control channel and its purpose is to acknowlodge the addition of a new data link between the two nodes. [Page 11] The format of the AddLinkAck message is as follows: ::= The AddLinkAck object has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MessageId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.4.3 AddLinkNack Message (MsgType = 27) The AddLinkNack message is sent over the control channel and its purpose is to deny the addition of a new data link between the two nodes. The format of the AddLinkNack message is as follows: ::= The AddLinkNack object has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MessageId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.5 Delete Link Messages 4.5.1 DeleteLink Message (MsgType = 28) The DeleteLink messsage is used to delete a data link. A data link added may either be a port or a component link. The format of the DeleteLink message is as follows: ::= The DeleteLink object has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MessageId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (DeleteLink TLVs) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MessageId: 32 bits When combined with the CCId, the MessageId field uniquely identifies a message. This value is incremented and only decreases when the value wraps. This is used for message acknowledgement in the DeleteLinkAck and DeleteLinkNack messages. [Page 12] 4.5.1.1 TE Link TLV The definition and format of the TE link TLV are defined in the Section 9.7.1.1 of [GMPLS-LMP]. 4.5.1.2 Data Link TLV The definition and format of the data link TLV are defined in the Section 9.7.1.2 of [GMPLS-LMP]. 4.5.2 DeleteLinkAck Message (MsgType = 29) A DeleteLinkAck is sent over the control channel and its purpose is to deny the deletion of a data link between the two nodes. The format of the DeleteLinkAck message is as follows: ::= The DeleteLinkAck object has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MessageId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.5.3 DeleteLinkNack Message (MsgType = 30) A DeleteLinkNack is sent over the control channel and its purpose is to deny the deletion of a data link between the two nodes. The format of the DeleteLinkNack message is as follows: ::= The DeleteLinkNack object has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MessageId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.0 Security Considerations Security issues are not discussed in this document. [Page 13] 6.0 References [CR-LDP] Jamoussi, et al., "Constraint-Basd LSP Setup using LDP", Internet Draft, draft-ietf-mpls-cr-ldp-05.txt, February 2001. [GMPLS-BUNDLE] Kompella/Rekhter/Berger, "Link Bundling in MPLS Traffic Engineering", Internet Draft, draft-kompella-mpls-bundle-05.txt, February 2001. [GMPLS-CRLDP] Ashwood-Smith, et al, "Generalized MPLS Signaling - CR-LDP Extensions", Internet Draft, draft-ietf-mpls-generalized-cr-ldp-02.txt, April, 2001. [GMPLS-HIER] Kompella/Rekhter, "LSP Hierarchy with MPLS TE", Internet Draft, draft-ietf-mpls-lsp-hierarchy-02.txt, February, 2000. [GMPLS-ISIS] Kompella, et al, "IS-IS Extensions in Support of Generalized MPLS", Internet Draft, draft-ietf-isis-gmpls-extensions-02.txt, February 2001. [GMPLS-LMP] Lang/Mitra, et al, "Link Management Protocol (LMP)", Internet Draft, draft-ietf-mpls-lmp-02.txt, March, 2001. [GMPLS-OSPF] Kompella, et al, "OSPF Extensions in Support of Generalized MPLS", Internet Draft, draft-kompella-ospf-gmpls-extensions-01.txt, February 2001. [GMPLS-RSVP] Ashwood-Smith, et al, "Generalized MPLS Signaling - RSVP-TE Extensions", Internet Draft, draft-ietf-mpls-generalized-rsvp-te-02.txt, April, 2001. [GMPLS-SIG] Ashwood-Smith, et al, "Generalized MPLS - Signaling Functional Description", Internet Draft, draft-ietf-mpls-generalized-signaling-04.txt, May 2001. [Page 14] [RSVP-TE] Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP Tunnels", Internet Draft, draft-ietf-mpls-rsvp-ls--tunnel-08.txt, February 2001. [UNNUM-CRLDP] Kompella/Rekhter/Kullberg, "Signaling Unnumbered Links in CR-LDR", Internet Draft, draft-ietf-mpls-crldp-unnum-01.txt, February, 2000. [UNNUM-RSVP] Kompella/Rekhter, "Signaling Unnumbered Links in RSVP-TE", Internet Draft, draft-ietf-mpls-rsvp-unnum-01.txt, November, 2000. 7.0 Authors' Addresses Dean Cheng Polaris Networks Inc. 6810 Santa Teresa Blvd. San Jose, CA 95119 Phone: +1 408 284 8061 Email: dcheng@polarisnetworks.com [Page 15]