CCAMP Working Group Dimitri Papadimitriou Category: Internet Draft Jim Jones Document: draft-papadimitriou-ccamp-lmp- Alcatel initiation-01.txt Expiration Date: December 2002 June 2002 (FA-)LSP Initiation using Link Management Protocol (LMP) draft-papadimitriou-ccamp-lmp-initiation-01.txt Status of this Memo 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 FA-LSP Initiation and Bundling process. [LMP] 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 FA-LSPs enabling among other to dynamically configure TE Links (in particular the LSP it can serve) between non-adjacent LSRs. 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-01.txt June 2002 3. Introduction The Link Management Protocol [LMP] protocol has demonstrate its 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 (aka link bundles). LMP currently consists of four main functions, of which, the first two are mandatory and the last two are optional (depending on the capabilities provided by the transport plane): 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. As such, this function enables the maintenance of the control plane adjacencies. This is performed using a Config message exchange followed by a lightweight keep-alive message exchange (aka Hello protocol). Link property correlation is used to aggregate multiple data links into a single TE Link and to synchronize their link properties. Link verification is used to verify the physical connectivity of the data bearing links and to exchange their identifiers (aka Discovery function). Fault management functions include alarm suppression and fault localization in both opaque and transparent networks. Note: control channel bootstrapping is described in [LMP-BOOT]. 4. FA-LSP Initiation and Bundling - Overview In this document, we extend the LMP capabilities to enable (FA-)LSP initiation and bundling. The usefulness of the proposed mechanism is illustrated by the following multiple LSP Regions case description: 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 (for instance, LSC) and the LSPs established through these nodes crosses the LSP region boundary at LSR(X) and LSR(Y) that belongs for instance to the TDM region (see [MPLS-HIER]). When dealing with non-PSC layers the LSP and TE Links are defined as the control plane mapping of the transport plane path and section entities (aka trails). Therefore, the LSP established at region n appears as a TE link at layer n+1 and are referred to as a Forwarding Adjacency LSP (FA-LSP). D.Papadimitriou - Internet Draft û Expires December 2002 2 draft-papadimitriou-ccamp-lmp-initiation-01.txt June 2002 Note: such hierarchy is referred to as ôhierarchical TE Linkö when the instance of the control plane having raised the LSP at layer n is distinct from the one using this link to setup an LSP at layer n+1. Corresponding considerations are outside out of the scope of this document. In this context, the main issues are on one hand related to the TE Link assignment performed at layer n while only its sub-components may be the object of a FA-LSP setup. Note also that once setup these FA-LSPs appear at layer n+1 with the interface switching capability having raised these LSPs at layer n. For instance, the triggering of an FA-LSP with TDM switching capability is only possible if both LSR(X) and LSR(Y) through the TE Links they define with their neighboring nodes (i.e. LSR(1) and LSR(N)) give access to an LSC switching capability region. Moreover, when an FA is dynamically triggered the TE attributes of its FA-LSP are inherited from the LSP, which induced its creation. On the other hand, the correlation of FAÆs having similar Traffic Engineering (TE) attributes can induce the creation of an FA bundle (here, in this example between LSR(X) and LSR(Y)) whose number of sub-components is at most as large as the number of sub-components of the TE Links defined between LSR(X) and LSR(1) and between LSR(N) and LSR(Y). 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. 5. (FA-)LSP Initiation (FA-)LSP initiation runs over an LMP adjacency and is invoked each time an LSP 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. 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 in this document. 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 D.Papadimitriou - Internet Draft û Expires December 2002 3 draft-papadimitriou-ccamp-lmp-initiation-01.txt June 2002 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, FA-LSP initiation 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). Note that the LSR(X) to LSR(Y) LMP session can use the same transport medium as the ingress and egress LMP sessions (these sessions may be used as entry point). This procedure consists of a sequence of LMP message exchanges between the ingress LSR(X) and egress LSR(Y) prior to the LSP establishment between these end-points. Consequently, when used, the FA-LSP initiation MUST be performed before the corresponding LSP is established. Once the FA-LSP has been initiated, it can be established and the created entity (i.e. the FA) used for path computation purposes by the upper LSP region as any other TE Link belonging to this region (see [MPLS-HIER]). 6. FA-LSP Verification After the FA-LSP establishment (see [GMPLS-SIG] and [MPLS-HIER]), verification of the newly created Lambda LSP at any time the FA-LSP is not in the property correlation process (see Section 6). This verification can be performed either using J0 Section Trace byte and out-of-band Test Message or in-band 16/64 byte J0 test message as described in [LMP]. In the latter case, procedure as described in [LMP] is used. In the former case, the out-of-band Test message is not transmitted using the J0 Section Trace byte i.e., over the data bearer link, but is sent over the ingress to egress LSR control channel and correlated for consistency to the received J0 pattern. In order to get the mapping between the Interface ID over which the out-of-band test message is sent and the J0 pattern sent in-band, the transmitting node must provide the correlation between this pattern and the out-of-band test message. This correlation is performed using the TRACE object as defined in [LMP-WDM] with Trace Type=1 or 2 for SONET or SDH, respectively. Note that verification can only be performed on already initiated and established FA-LSPs. 7. FA-LSP Bundling The messages defined in [LMP] for Link Property Correlation are used for FA-LSP bundling purposes: LinkSummary (MsgType = 14), D.Papadimitriou - Internet Draft û Expires December 2002 4 draft-papadimitriou-ccamp-lmp-initiation-01.txt June 2002 LinkSummaryAck (MsgType = 15) and LinkSummaryNack (MsgType = 16). The contents of these messages are built using existing (see [LMP] Section 13) and additional LMP sub-objects, 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 has established an FA-LSP and wants to add/remove this FA-LSP from an existing bundle of FA-LSPs, it sends a LinkSummary message to the egress LSR indicating its local TE Link and data bearing link information (including status and availability) while requesting the corresponding information from the remote side. Since the ingress LSR can be aware of the remote node TE Link and data bearing link information, this request MAY include the remote side information. The LinkSummary message can also be used to aggregate simultaneously multiple established FA-LSP into a bundle of FA-LSPs. In addition to add/remove an FA-LSP from an existing bundle of FA-LSPs, it can also change the FA-LSPs correlation parameters. 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 LinkSummary 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 LinkSummaryAck message is used to signal an agreement (including availability and status) on ALL the parameters both negotiable and non-negotiable received in the LinkSummaryAck 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 LinkSummary message. Otherwise, a LinkSummaryNack 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 LinkSummaryNack 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 LinkSummaryNack message includes negotiable parameters, then acceptable values for those parameters MUST be included. If a D.Papadimitriou - Internet Draft û Expires December 2002 5 draft-papadimitriou-ccamp-lmp-initiation-01.txt June 2002 LinkSummaryNack message is received and includes negotiable parameters, then the initiator of the LinkSummary message MUST send a new LinkSummary message that SHOULD include new values for the negotiable parameters. These values SHOULD take into account the acceptable values received in the LinkSummaryNack message. 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 LinkSummary message. The timer is reset if an LinkSummaryAck or LinkSummaryNack message is received for this message. The expiry of this timer results in the retransmission of the LinkSummary 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 LinkSummary 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 LinkSummaryAck/Nack after having issued a second (or subsequent) LinkSummary message after retransmission timer expiration, only the last LinkSummaryAck/Nack message is considered by the initiator. 8. Security Considerations LMP provides authentication on a per IP Control Channel basis. The packet authentication procedure is very similar to the one used in OSPF, including multiple key support, key management, etc. The details specific to LMP are defined in [LMP] Section 13.3. 9. References [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC-2219] 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. D.Papadimitriou - Internet Draft û Expires December 2002 6 draft-papadimitriou-ccamp-lmp-initiation-01.txt June 2002 [GMPLS-RTG] Kompella, K., et al, ôRouting Extensions in Support of Generalized MPLS,ö Internet Draft, Work in Progress, draft-ietf-ccamp-gmpls-routing-04.txt, May 2002. [GMPLS-SIG] Ashwood-Smith, P., et al, ôGeneralized MPLS û signaling functional description,ö Internet Draft (work in progress), draft-ietf-mpls-generalized-signaling- 08.txt, April 2002. [LMP] Lang, J.P. (Editor), et al, ôLink Management Protocol,ö Internet Draft (work in progress), draft-ietf-ccamp- lmp-04.txt, June 2002. [LMP-BOOT] Lang, J.P., Drake, J. and Papadimitriou, D., ôControl Channel Bootstrap for LMP,ö Internet Draft (work in progres), draft-lang-ccamp-lmp-bootstrap-00.txt, June 2002. [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-03.txt, May 2002. [MPLS-HIER] Kompella, K. and Rekhter, Y., ôLSP Hierarchy with Generalized MPLS TEö, Internet Draft (work in progress, draft-ietf-mpls-lsp-hierarchy-06.txt, May 2002. 10. Acknowledgments The authors would like to thank Bernard Sales, Emmanuel Desmet, Gert Grammel, Mike Sexton and John Drake for their constructive comments and input. 11. Author's Addresses 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 December 2002 7