CCAMP Working Group D. Papadimitriou Category: Internet Draft J. Jones Document: draft-papadimitriou-ccamp-lmp- Alcatel initiation-00.txt Expiration Date: August 2002 February 2002 LSP Initiation using Link Management Protocol (LMP) draft-papadimitriou-ccamp-lmp-initiation-00.txt Status of this Memo All Internet-Drafts must begin with ONE of the following three statements: This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. For potential updates to the above required-text see: http://www.ietf.org/ietf/1id-guidelines.txt 1. Abstract This memo is a companion document to Link Management Protocol [LMP], for which it details the LSP Initiation process when using. This protocol is being developed as part of the GMPLS protocol suite to control and manage traffic engineering (TE) links. The current document extends the LMP capabilities to LSP enabling among other to dynamically configure a TE-link (in particular the LSP it can serve) between non-adjacent LSR. 2. 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 [2]. D.Papadimitriou Internet Draft û Expires AugustÆ02 1 draft-papadimitriou-ccamp-lmp-initiation-00.txt February 2002 3. Introduction The Link Management Protocol [LMP] protocol has demonstrate is value in automating Generalized MPLS (GMPLS) operations. This protocol is being developed as part of the GMPLS protocol suite to control and manage traffic engineering (TE) links. LMP currently consists of four main functions, of which, the first two are mandatory and the last two are optional: 1. Control channel management 2. Link property correlation 3. Link verification 4. Fault management Control channel management is used to establish and maintain control channel connectivity between adjacent nodes. This is performed using a Config message exchange followed by a lightweight keep-alive message exchange. Link property correlation is used to aggregate multiple data links into a single TE Link and to synchronize the link properties. Link verification is used to verify the physical connectivity of the data links and to exchange the data link Ids. Fault management is used to suppress alarms (alarm suppression) and to localize failures in both opaque and transparent networks (fault localization). In this document, we extend the LMP capabilities to LSP initiation. The usefulness of the proposed mechanism is illustrated by the following case description: Case 1: Single LSP Region LSR(X) <--------------------- LMP ---------------------> LSR(Y) ^ ^ | | |LMP LMP| | | v v LSR(1) <--LMP--> LSR(2) <--.. LMP ..--> LSR(i) <--LMP--> LSR(N) In this case there is no LSP region boundary crossing (see [MPLS- HIER]): all LSR have the same interface switching capability and the same Link Encoding Type (see [GMPLS-SIG]). This example applies for instance when LSR(X) and LSR(Y) are the ingress and egress of a Lambda LSP while each LSR(i) includes only LSC capable interfaces (see [GMPLS-RTG]). In such a case, the LSP established between LSR(X) and LSR(Y) does not has necessarily all the information needed to establish the connection between LSR(X) and LSR(Y). This could happen for several reasons: this information is not exchanged either through the TE- routing protocol (see [GMPLS-OSPF-TE] and [GMPLS-ISIS-TE]) or for D.Papadimitriou Internet Draft û Expires AugustÆ02 2 draft-papadimitriou-ccamp-lmp-initiation-00.txt February 2002 scalability reasons (for instance, large amount of SRLGs) this information is not exchanged throughout the network. Another reason could be for instance that some TE attributes such as Link Protection TLV (see [GMPLS-RTG]) are not advertised by LSR(Y) because this node bundles link with different link protection capabilities. Last since any LSP has been established between these two LSRs, no RSVP-TE session exist consequently none of the signalling-based (RSVP-TE, for instance) fast notification would be capable to notify the ingress of any intermediate and/or egress link failure. Consequently, status and availability of the egress LSR (including its interfaces) resources are strictly dependent upon the IGP-TE update and database convergence. Taking the assumption that the time(update + database convergence) >> time(request arrival + LSP setup), an additional mechanism is needed at the ingress LSR(X) to directly exchange resource availability and status information with LSR(Y). Case 2: Multiple LSP Regions LSR(X) <--------------------- LMP ---------------------> LSR(Y) N+1 | | | | | | LSR(X) <--LMP--> LSR(1) <--.. LMP ..--> LSR(N) <--LMP--> LSR(Y) N Typically, LSR(1) to LSR(N) belongs to one LSP region, and the LSP established through crosses region boundary at LSR(X) and LSR(Y) (see [MPLS-HIER]). The LSP established at region N appears as a link at layer N+1 and called a ôforwarding adjacencyö. The fundamental point when dealing with non-PSC layers is that these concepts are translated within the control plane instance mapping the transport plane LSP/Link topological. Such hierarchy is also referred to as ôhierarchical TE-Linkö. Note: there is a similarity between this and the context where [LMP- WDM] protocol is defined: LSR(X) and LSR(Y) corresponds to OXC and LSR(1) to LSR(N) to Optical Line System (OLS); the only exception is that in the latter case, one of the LMP neighbor is a non GMPLS- capable node. Case 2 will be covered in more details in a future release of this document. 5. LSP Initiation LSP Initiation runs over an LMP adjacency and is invoked each time a connection is setup between a pair of ingress-egress LSR belonging to the same LSP region. To initiate an LMP adjacency between these nodes at least one bi-directional control channel MUST be activated. D.Papadimitriou Internet Draft û Expires AugustÆ02 3 draft-papadimitriou-ccamp-lmp-initiation-00.txt February 2002 Once an LMP adjacency has been brought up, LMP session information can start between the ingress-egress LSR pair. The exact implementation of this control channel is not specified here. It could be, for example, a dedicated wavelength, an Ethernet link, or an IP tunnel defined between LSR(1) ingress and LSR(N) egress, or even the overhead bytes of a data-bearing link. Rather, a node-wide unique 32-bit non-zero integer control channel identifier (CCId) is assigned at each end of the control channel. This identifier comes from the same space as the unnumbered interface Id. The control channel defined between LSR(X) and LSR(Y) is either permanently maintained (in this case the control channel is explicitly configured) or established on-demand (in this case the control channel is dynamically configured and selected). As described in [LMP] (see Section 3), once a control channel is activated between two nodes, the LMP Hello protocol (see [LMP] Section 3.2) can be used to maintain control channel connectivity between the nodes and to detect control channel failures. This protocol is intended to be a lightweight keep-alive mechanism that will react to control channel failures rapidly. Therefore, LSP initiation procedure that can be invoked only after control channel setup completion between LSR(X) and LSR(Y) but also between LSR(X) and LSR(1) at the head-end (ingress) and between LSR(N) and LSR(Y) at the tail-end (egress). The latter because the LSR(X) to LSR(Y) LMP session can use the same transport medium as the ingress and egress LMP sessions; but also these end session can be used as entry point. This procedure consists of a sequence of (new) LMP message exchanges between the ingress LSR(X) and egress LSR(Y) prior to the LSP establishment between these end-points. Therefore, when used, the LSP initiation MUST be performed before the LSP is established. Three new types of messages are used for this purpose: LSP Initiation (MsgType = TBA), LSP Initiation Ack (MsgType = TBA) and LSP Initiation Nack (MsgType = TBA). The contents of these messages are built using existing (see [LMP] Section 13) and additional LMP objects (see Section 4), which can be either negotiable or non- negotiable. Here, negotiable objects are used to let both sides agree on the acceptance of certain parameters for the requested LSP. Non-negotiable objects are used for announcement of specific values that do not need, or do not allow, negotiation. These messages are exchanged between the ingress and the egress LSR (through the control channel) and used as follows. When the ingress LSR wants to establish an LSP, it sends a LSPInitiation message to the egress LSR indicating its local TE and data bearing link information (including status and availability) while requesting the corresponding information from the remote side. Since the ingress can be aware of the remote side TE and data bearing link information, this request MAY include the remote side information. D.Papadimitriou Internet Draft û Expires AugustÆ02 4 draft-papadimitriou-ccamp-lmp-initiation-00.txt February 2002 In such a case, the requestor uses the LSPInitiation message for status/availability acknowledgement from the remote side. This message can subsequently be used to aggregate multiple links (i.e. the established FA-LSP) into a TE link; exchange, correlate (to determine inconsistencies), or change TE link parameters; and exchange, correlate (to determine inconsistencies), or change Interface Ids (i.e. the Component Interface Ids). Remember here that each TE link has an identifier (TE Link_Id) that is assigned at each end of the TE link. These identifiers MUST be the same type (i.e, IPv4, IPv6, unnumbered) at both ends. Similarly, each component interface is assigned an identifier (Interface_Id) at each end. These identifiers MUST be the same type at both ends. Interface Id values MUST be taken from the space used for local LMP sessions. If the LSPInitiation message is received from a remote node and the Interface Id mappings match those that are stored locally, then the two nodes have agreement on Interface Id and TE Link Id if these are known by the ingress. The LSPInitiationAck message is used to signal an agreement (including availability and status) on ALL the parameters both negotiable and non-negotiable received in the LSPInitiation message. This agreement includes the Interface Id mapping and Link Property definitions as well as the TE Link Id mapping if the latter are known by the ingress LSR. Moreover, when sending such a message, the receiverÆs data links support the capabilities listed in the LSPInitiation message. Otherwise, a LSPInitiationNack message MUST be sent as response to indicated which Interface Id mappings are not correct and/or which data bearing link properties are not accepted. If a LSPInitiation Nack message indicates that the Interface Id mappings are not correct it means that an error from a previous information has occurred (such issues are outside of the scope of this document). If a LSPInitiationNack message includes negotiable parameters, then acceptable values for those parameters MUST be included. If a LSPInitiationNack message is received and includes negotiable parameters, then the initiator of the LSPInitiation message MUST send a new LSPInitiation message that SHOULD include new values for the negotiable parameters. These values SHOULD take into account the acceptable values received in the LSPInitiationNack message. The following additional objects are defined for LSP Initiation message purpose (in addition to the usual LMP Header, NODE_ID and MESSAGE_ID as specified in [LMP] Section 13): - LOCAL and REMOTE DATA_LINK object with additional (see also [LMP]) sub-object defined in Section 7 of this document - LOCAL and REMOTE TE_LINK object defined in Section 7 D.Papadimitriou Internet Draft û Expires AugustÆ02 5 draft-papadimitriou-ccamp-lmp-initiation-00.txt February 2002 Last, the following data structures are maintained at the ingress (LSP initiator) and the egress (LSP receptor or destinator) LSR: - Retransmission Timer, r: This configurable timer is set by a node sending a LSPInitiation message. The timer is reset if an LSPInitiationAck or LSPInitiationNack message is received for this message. The expiry of this timer results in the retransmission of the LSPInitiation message. The default value of this timer is 1 second. - Number of Retransmissions, n: This configurable parameter indicates the maximum number of allowed retransmissions of LSPInitiation messages. The default value of this number is 3. A node considers the LSP Initiation procedure to have failed if a response is not received from the peer after n retransmission attempts. Note: if the ingress LSR i.e. the LSP initiator, receives more than one LSPInitiationAck/Nack after having issued a second (or subsequent) LSPInitiation message after retransmission timer expiration, only the last LSPInitiationAck/Nack message is considered by the initiator. - LSP Initiation Success Flag: This flag is set when the node executing the FSM determines that service discovery has been successfully completed. Initial value is FALSE. Finite State Machine: TBD. 6. A Step Further After the LSP establishment (see [GMPLS-SIG]), an OPTIONAL verification of the newly created Sonet/SDH STS SPE/HO (or VT/LO) LSP using J1 (or J2, respectively) Trace and out-of-band Test Message can be performed LSP appears as. The J1 (and J2) Path Trace byte are described in [G.707] and [T1.105]. Note that any other verification mechanism as described in [LMP] can also be used for that purpose. The out-of-band Test message is not transmitted using the J1 (or J2) bytes i.e., over the data link, but is sent over the ingress to egress LSR control channel and correlated for consistency to the received J1 (or J2) pattern. In order to get the mapping between the Interface ID over which the J1 test message is sent and the J1 pattern sent in-band, the transmitting node must provide the correlation between this pattern and the J1 test message. This correlation is done using the TRACE object as defined in [LMP-WDM] with Trace Type = 2 or 4 for SONET or SDH, respectively. D.Papadimitriou Internet Draft û Expires AugustÆ02 6 draft-papadimitriou-ccamp-lmp-initiation-00.txt February 2002 7. LMP Message Formats This section describes the specific LMP messages defined for LSP Initiation purposes: LSPInitiation Message (Section 7.1), LSPInitiationAck Message (Section 7.2) and LSPInitiationNack Message (Section 7.3). 7.1 LSPInitiation Message (MsgType = TBA) The LSPInitiation message is an LMP message sent in an IP packet over the ingress to egress LSR control channel. In addition, to the LOCAL NODE_ID and the MESSAGE_ID, this message includes the information (see LOCAL_DATA_LINK and REMOTE_DATA_LINK sub-objects) related to the LOCAL data bearing links included within the same TE Link, referenced by the LOCAL TE LINK Object. The REMOTE_DATA_LINK corresponding to the REMOTE TE LINK Object SHOULD be included if the corresponding mapping is already known by the initiator. The LSPInitiation message has the following format: ::= [] [] [ []] [...[...]] The above transmission order SHOULD be followed. The definitions of the message content is as follows: - is defined in [LMP] Section 13.1 - NODE ID Object (Class = 3) is the LOCAL_NODE_ID Object (C-Type = 1) see [LMP] Section 14.2 for details - MESSAGE ID Object (Class = 9) is the Type 1 MESSAGE_ID Object (C- Type = 1) see [LMP] Section 14.3 for details - LOCAL TE LINK_Object (Class = TBA) : see Section 8.4 - REMOTE TE LINK Object (Class = TBA) : see Section 8.5 - LOCAL_DATA_LINK Object (Class = TBA) : see Section 8.2 - REMOTE_DATA_LINK Object (Class = TBA): see Section 8.3 7.2 LSPInitiationAck Message (MsgType = TBA) The LSPInitiationAck message indicates that ALL the parameters (both negotiable and non-negotiable) received in the LSPInitiation message are acceptable by the receiving node. Therefore, the LSPInitiation Ack message indicates that the receiverÆs data links support the same capabilities than the one indicated in the LSPInitiation message. So, the LOCAL_DATA_LINK and REMOTE_DATA_LINK objects MUST not include any sub-object but only the corresponding Interface Ids (see Section 8.2 and 8.3, respectively). D.Papadimitriou Internet Draft û Expires AugustÆ02 7 draft-papadimitriou-ccamp-lmp-initiation-00.txt February 2002 The LSPInitiationAck message is an LMP message sent in an IP packet from the egress to the ingress LSR with the IP destination address set to the NODE_ID value received in the corresponding LSP Initiation message. The LSPInitiationAck message has the following format: ::= [ ] [...] The above transmission order SHOULD be followed. The definitions of the message content is as follows: - is defined in [LMP] Section 13.1 - NODE ID Object (Class = 3) is the LOCAL_NODE_ID Object (C-Type = 1) see [LMP] Section 14.2 for details - MESSAGE ID Object (Class = 9) is the Type 2 MESSAGE_ID Object (C- Type = 1) see [LMP] Section 14.3 for details - LOCAL TE LINK Object (Class = TBA) : see Section 8.4 - REMOTE TE LINK Object (Class = TBA) : see Section 8.5 - LOCAL_DATA_LINK Object (Class = TBA) : see Section 8.2 - REMOTE_DATA_LINK Object (Class = TBA): see Section 8.3 7.3 LSP Initiation Nack Message (MsgType = TBA) The LSPInitiationNack message is used to acknowledge receipt of the LSPInitiation message AND to indicate which (if any) of the non- negotiable parameters are unacceptable and propose (if any) alternate values for the negotiable parameters. The content of the LSPInitiationNAck message is then defined as: - If the receiverÆs data links properties set is not disjoint from the one supported by the sender i.e. it supports additional or even less properties than the one indicated in the LSPInitiation message, the egress LSR includes the capabilities it supports for the corresponding REMOTE TE LINK into the sub-objects of the REMOTE_DATA_LINK objects in the LSPInitiationNack message. - If the receiverÆs data links properties set is completely disjoint from the one supported by the sender, the REMOTE_DATA_LINK sub- objects MUST be empty. This means that the initiation procedure can not be accepted by the receiver and subsequently that a connection can not be established between the sender and the receiverÆs data link. The LSPInitiationNack message is an LMP message sent in an IP packet sent from the egress to the ingress LSR, with the IP destination address set to the NODE_ID received in the corresponding LSPInitiation message. The LSPInitiationNack message has the following format: D.Papadimitriou Internet Draft û Expires AugustÆ02 8 draft-papadimitriou-ccamp-lmp-initiation-00.txt February 2002 ::= [ ] [...] The above transmission order SHOULD be followed. The definitions of the message content is as follows: - is defined in [LMP] Section 13.1 - NODE ID Object (Class = 3) is the LOCAL_NODE_ID Object (C-Type = 1) see [LMP] Section 14.2 for details - MESSAGE ID Object (Class = 9) is the Type 2 MESSAGE_ID Object (C- Type = 1) see [LMP] Section 14.3 for details - LOCAL TE LINK Object (Class = TBA) : see Section 8.4 - REMOTE TE_LINK Object (Class = TBA) : see Section 8.5 - LOCAL_DATA_LINK Object (Class = TBA) : see Section 8.2 - REMOTE_DATA_LINK Object (Class = TBA): see Section 8.3 8. LMP Object Definitions All LMP messages (expect some particular Test messages) are IP encoded and shares a common header (see [LMP] section 13.1). LMP messages are built using objects. Each object is identified by its Object Class-Num and Class-type. Messages and Objects defined in the scope of LSP Initiation process are specified in this document. LMP objects can be either negotiable or non-negotiable (identified by the N bit in the TLV header). Negotiable objects can be used to let the devices agree on certain values. Non-negotiable Objects are used for announcement of specific values that do not need or do not allow negotiation. 8.1 LMP Object Format The format of the LMP object is defined in [LMP] Section 13.2. 8.2 LOCAL DATA_LINK Class (Class = TBA) The objects belonging to the LOCAL_DATA_LINK Class (Class = TBA) are defined as follows: - IPv4 (C-Type = 1) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local_Interface_Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Subobjects) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D.Papadimitriou Internet Draft û Expires AugustÆ02 9 draft-papadimitriou-ccamp-lmp-initiation-00.txt February 2002 - IPv6 (C-Type = 2) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Local_Interface_Id (16 bytes) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Subobjects) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Unnumbered (C-Type = 3) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local_Interface_Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Subobjects) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags (8 bits) The following flags are defined. All other values are reserved. 0x01 Interface Type: If set, the data link is a port, otherwise it is a component link. 0x02 Allocated Link: If set, the data link is currently allocated for user traffic. If a single Interface_Id is used for both the transmit and receive data links, then this bit only applies to the transmit interface. Local_Interface_Id D.Papadimitriou Internet Draft û Expires AugustÆ02 10 draft-papadimitriou-ccamp-lmp-initiation-00.txt February 2002 This is the local identifier of the data link. This MUST be node-wide unique and non-zero. Data Link Sub-objects The contents of the LOCAL_DATA_LINK object consist of a series of variable-length data items called sub-objects. These sub- objects are defined below. A LOCAL_DATA_LINK object may contain more than one sub-object. If more than one sub-object of the same Type appears, only the first sub-object of that Type is meaningful. Subsequent sub- objects of the same Type MAY be ignored. The content of the LOCAL_DATA_LINK object includes a series of variable-length data items called sub-objects. The format the Data Link sub-object is defined in [LMP] Section 14.13.1. Sub-object 1: Interface Switching Capability (see [LMP] Section 14.13.1) Sub-object 2: Sonet/SDH Interface Capability (Type = 2, Length = 12) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 2 | Length = 16 | Signal Type | Transparency | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum NCC | Maximum NCC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum NVC | Maximum NVC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Link Protection| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signal Type (8 bits) This field indicates all the possible non-concatenated signals (also referred to as ôelementaryö signals) supported by a given data link for the corresponding. This parameter is interpreted in relation to the Encoding Type field value. Permitted values for SONET links and SDH links are defined in [GMPLS-SONET-SDH]. Transparency (8 bits) This field is defined as a vector of flags (bit 1 is the low order bit) which indicates the Transparency level(s) supported by an end-point data bearer link: Flag 1 (bit 1): Path/VC Overhead Transparency (default) Flag 2 (bit 2): Line/MS Overhead Transparency D.Papadimitriou Internet Draft û Expires AugustÆ02 11 draft-papadimitriou-ccamp-lmp-initiation-00.txt February 2002 Flag 3 (bit 3): Section/RS Overhead Transparency Flag 4 to Flag 8 (bit 4 to 8): Reserved for future use The flag is set to 1 if the corresponding transparency is supported otherwise it MUST be set to 0. Reserved values MUST be set to 0. When end-point transparency level, all flags MUST be set to 0 except Flag 1 (POH Transparency). Minimum Number of Contiguously concatenated Components (16 bits) This field specifies the minimum number of contiguously concatenated components applicable to a VC-4 or STS-3c SPE (see [GMPLS-SONET-SDH]). When the interface does not support contiguous concatenation, then Minimum NCC must be set to zero when sent and ignored when received. When the interface supports contiguous concatenation, then the Minimum NCC value must be at least equal to 1. Maximum Number of Contiguously concatenated Components (16 bits) This field specifies the maximum number of contiguously concatenated components applicable to a VC-4 or STS-3c SPE signal (see [GMPLS-SONET-SDH]). When the interface does not support contiguous concatenation, then Maximum NCC must be set to zero when sent and ignored when received. When the data link supports contiguous concatenation, then the Maximum NCC value must be at least equal to 1. Minimum Number of Virtually concatenated Components (16 bits) This field specifies the minimum number of virtually concatenated components applicable to a VC-3/VC-4 or STS-1 SPE/STS-3c SPE (see [GMPLS-SONET-SDH]). When the interface does not support virtual concatenation, then Minimum NVC must be set to zero when sent and ignored when received. When the data link supports virtual concatenation, then the Minimum NVC value must be at least equal to 1. Maximum Number of Virtually concatenated Components (16 bits) This field specifies the maximum number of virtually concatenated components applicable to a VC-3/VC-4 or STS-1 SPE/STS-3c SPE (see [GMPLS-SONET-SDH]). When the interface does not support virtual concatenation, then Maximum NVC must be set to zero when sent and ignored when received. When the data link supports virtual concatenation, then the Maximum NVC value must be at least equal to 1. Link Protection (8 bits) D.Papadimitriou Internet Draft û Expires AugustÆ02 12 draft-papadimitriou-ccamp-lmp-initiation-00.txt February 2002 The Link Protection is a bit vector describing the protection capabilities of the end-point data link. Link protection types are defined in [GMPLS-RTG]. The corresponding values are: 0x01 Extra Traffic 0x02 Unprotected 0x04 Shared 0x08 Dedicated 1:1 0x10 Dedicated 1+1 0x20 Enhanced 0x40 Reserved 0x80 Reserved 8.3 REMOTE DATA_LINK Class (Class = TBA) The objects belonging to the REMOTE DATA_LINK Class (Class = TBA) are defined as follows: - IPv4 (C-Type = 1) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote_Interface_Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Subobjects) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - IPv6 (C-Type = 2) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Remote_Interface_Id (16 bytes) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Subobjects) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D.Papadimitriou Internet Draft û Expires AugustÆ02 13 draft-papadimitriou-ccamp-lmp-initiation-00.txt February 2002 - Unnumbered (C-Type = 3) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote_Interface_Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Subobjects) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags (8 bits) The following flags are defined. All other values are reserved. 0x01 Interface Type: If set, the data link is a port, otherwise it is a component link. 0x02 Allocated Link: If set, the data link is currently allocated for user traffic. If a single Interface_Id is used for both the transmit and receive data links, then this bit only applies to the transmit interface. Local_Interface_Id This is the local identifier of the data link. This MUST be node-wide unique and non-zero. Data Link Sub-objects The contents of the REMOTE_DATA_LINK object consist of a series of variable-length data items called sub-objects. These sub- objects are defined below. A REMOTE_DATA_LINK object may contain more than one sub-object. If more than one sub-object of the same Type appears, only the first sub-object of that Type is meaningful. Subsequent sub- objects of the same Type MAY be ignored. The content of the REMOTE_DATA_LINK object includes a series of variable-length data items called sub-objects. The format the Data Link sub-object is defined in [LMP] Section 14.13.1. Sub-object 1: Interface Switching Capability (see [LMP] Section 14.13.1) D.Papadimitriou Internet Draft û Expires AugustÆ02 14 draft-papadimitriou-ccamp-lmp-initiation-00.txt February 2002 Sub-object 2: Sonet/SDH Interface Capability (see Section 8.2) 8.4 LOCAL TE LINK Class (Class = TBA) This object is non-negotiable. - IPv4 (C-Type = 1) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local_Link_Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - IPv6 (C-Type = 2) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Local_Link_Id (16 bytes) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Unnumbered (C-Type = 3) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local_Link_Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags (8 bits) The following flags are defined. All other values are reserved - 0x01 Fault Management Supported - 0x02 Link Verification Supported Local_Link_Id This identifies the nodeÆs local Link Id and MUST be non-zero. 8.5 REMOTE TE LINK Class (Class = TBA) D.Papadimitriou Internet Draft û Expires AugustÆ02 15 draft-papadimitriou-ccamp-lmp-initiation-00.txt February 2002 This object is non-negotiable. - IPv4 (C-Type = 1) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote_Link_Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - IPv6 (C-Type = 2) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Remote_Link_Id (16 bytes) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Unnumbered (C-Type = 3) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote_Link_Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags (8 bits) The following flags are defined. All other values are reserved - 0x01 Fault Management Supported - 0x02 Link Verification Supported Remote_Link_Id This identifies the nodeÆs local Link Id and MUST be non-zero. 9. Security Considerations LMP provides authentication on a per IP Control Channel basis. The packet authentication procedure is very similar to the one D.Papadimitriou Internet Draft û Expires AugustÆ02 16 draft-papadimitriou-ccamp-lmp-initiation-00.txt February 2002 used in OSPF, including multiple key support, key management, etc. The details specific to LMP are defined in [LMP] Section 13.3. 10. References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [G.707] ITU-T G.707, ôNetwork node interface for the synchronous digital hierarchy (SDH),ö March 1996. [GR.253] GR-253-CORE, ôSynchronous Optical Network (SONET) Transport Systems: Common Generic Criteria,ö Telcordia Technologies, Issue 3, September 2000. [GMPLS-RTG] Kompella, K., et al, ôRouting Extensions in Support of Generalized MPLS,ö Internet Draft, Work in Progress, draft-kompella-ccamp-gmpls-routing-01.txt, February 2002. [GMPLS-SIG] Ashwood-Smith, P., et al, ôGeneralized MPLS û signaling functional description,ö Internet Draft (work in progress), draft-ietf-mpls-generalized-signaling- 07.txt, November 2001. [LMP] Lang, J. P., et al, ôLink Management Protocol,ö Internet Draft (work in progress), draft-ietf-ccamp- lmp-02.txt, November 2001. [LMP-WDM] Fredette, A., Lang, J. P., editors, ôLink Management Protocol (LMP) for DWDM Optical Line Systems,ö Internet Draft (work in progress), draft-ietf-ccamp-lmp-wdm- 00.txt, February 2002. [MPLS-BUND] Kompella, K. et al., ôLink Bundling in MPLS Traffic Engineeringö, Internet Draft (work in progress), draft- ietf-mpls-bundle-01.txt, November 2001. [MPLS-HIER] Kompella, K. and Rekhter, Y., ôLSP Hierarchy with Generalized MPLS TEö, Internet Draft (work in progress), draft-ietf-mpls-lsp-hierarchy-04.txt, February 2002. 10. Acknowledgments The authors would like to thank Bernard Sales, Emmanuel Desmet, Gert Grammel and Mike Sexton for their constructive comments and inputs. 11. Author's Addresses D.Papadimitriou Internet Draft û Expires AugustÆ02 17 draft-papadimitriou-ccamp-lmp-initiation-00.txt February 2002 Dimitri Papadimitriou Alcatel Francis Wellesplein, 1 B-2018 Antwerpen, Belgium Phone: +32 3 240 8491 Email: dimitri.papadimitriou@alcatel.be Jim Jones Alcatel 3400 W. Plano Parkway, Plano, TX 75075, USA Phone: +1 972 519-2744 Email: jim.d.jones1@usa.alcatel.com D.Papadimitriou Internet Draft û Expires AugustÆ02 18