CCAMP Working Group D.Papadimitriou Internet Draft (Alcatel) Expiration Date: August 2004 D.Brungard (ATT) M.Vigoureux (Alcatel) February 2004 Generalized MPLS (GMPLS) RSVP-TE Signaling in support of Layer-2 Label Switched Paths (LSP) draft-papadimitriou-ccamp-gmpls-l2sc-lsp-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. 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 Abstract Most efforts on Generalized MPLS (GMPLS) have been focused to environments covering Circuit oriented LSPs (Sonet/SDH, OTH, etc.). There is minimal documentation on GMPLS support of Layer-2 Label Switched Paths (L2 LSPs), e.g. native Ethernet LSPs. This document details GMPLS capabilities for supporting L2 LSPs in several network environments including overlays. As such, it provides a reference detailing the applicability of GMPLS for Ethernet switching environments in support of various deployment scenarios, including the integrated (e.g. multi LSP-region networks), the augmented/peer and the overlay model (e.g. Generalized VPN (GVPN) and user-network interfaces (GMPLS UNI)). D.Papadimitriou et al. - Expires August 2004 1 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-01.txt February 2004 1. 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. In addition the reader is assumed to be familiar with the concepts developed in [GMPLS-ARCH], [RFC-3471], [RFC-3473], [RFC-3477], and [GMPLS-UNI], [GMPLS-ENNI] as well as [MPLS-HIER] and [MPLS-BDL]. The following abbreviations are used in this document: CN: Core node EN: Edge node ICN: Ingress core node ECN: Egress core node FA: Forwarding Adjacency FSC: Fiber-Switch Capable HOVC: Higher order virtual container ISC: Interface Switching Capability L2-LSP: Layer-2 Label Switched Path L2SC: Layer-2 Switch Capable LOVC: Lower order virtual container LSC: Lambda Switch Capable PSC: Packet Switch Capable OTH: Optical transport hierarchy SDH: Synchronous digital hierarchy. SONET: Synchronous Optical Network. TDM: Time-Division Multiplex 2. Introduction Generalized Multi-Protocol Label Switching (GMPLS) extends MPLS to support four new classes of interfaces Layer-2 Switch Capable (L2SC), Time-Division Multiplex (TDM), Lambda Switch Capable (LSC) and Fiber-Switch Capable (FSC) in addition to Packet Switch Capable (PSC) already supported by MPLS. All these interface classes have been considered in [GMPLS-ARCH], [GMPLS-RTG] and [RFC-3471]. However, most of the efforts have been concentrated in facilitating the realization of seamless control integration of IP/MPLS networks with SONET/SDH (see [T1.105]/[G.707]) or OTH (see [G.709]) optical transport networks. The integration of packet and circuit switching technologies under a unified GMPLS control plane provides an homogeneous control management approach for both provisioning resources and recovery techniques (including protection and re- routing). While being introduced in [GMPLS-ARCH], [GMPLS-RTG] and [RFC-3471], the GMPLS capability to control L2SC TE links and Layer-2 LSPs has received very little attention. [RFC-3471] defines the Ethernet encoding types (i.e. the encoding of the LSP being requested) and Layer-2 as switching capability (i.e. the type of switching to be D.Papadimitriou et al. - Expires August 2004 2 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-01.txt February 2004 performed on a particular link). In this document, a Layer-2 LSP is defined as a LSP being established between L2SC interfaces. These interfaces are defined as being capable of recognizing frame/cell boundaries and can switch data based on the content of the frame/cell header (example: interfaces on Ethernet switches that switch data based on the content of the MAC header). The motivation for considering GMPLS control of Layer-2 LSPs can be summarized as follows: - it automates the provisioning of transparent LAN services. Today, the delivery of such services can not be automated due to the control plane/topology driven nature of GMPLS that precludes the automated triggering of the server layer LSP. - it facilitates the transport of Ethernet flows without introducing additional intermediate packet layer LSPs that require themselves manual provisioning actions. - it delivers control plane driven recovery capabilities for a range of technologies (e.g. Ethernet) making classically usage of mechanisms adapted only for environments where these data plane technologies had been initially introduced. For instance, Ethernet Spanning Tree Protocol is less suitable in meshed environments where control plane driven fast recovery is required and available - it simplifies the carrier network operations by avoiding dedicated control protocols for managing Ethernet environments that are not adapted for large scale environments and for which an IP-based protocol counter-part exists (e.g. OSPF). - the use of an IP based addressing scheme elevates the scaling issues generated by the non-hierarchical MAC addressing scheme. This capability allows constructing large scale networks taking advantage of the IP addressing properties. 3. Context The reference network considered (but not restricted to) in this document is provided in [GMPLS-UNI] and [GMPLS-ENNI]. 3.1 GMPLS UNI This network is constituted by a core network including core-nodes (CN) surrounded by edge nodes (EN) that form the overlay networks. In addition, the present document assumes that edge and core nodes are connected by point-to-point native Ethernet interfaces (whose bit rate can vary from 10Mbps to 10Gbps and more in the future). Thus the Traffic Engineering (TE) links inter-connecting the edge and the core nodes are of type [X,L2SC], where X is any ISC whose switched payload can be carried over L2SC TE links. Within the network, the links interconnecting the core nodes can be either [L2SC,L2SC] or any other technology that can carry Layer-2 Ethernet payload, in particular [TDM,TDM] and [LSC,LSC]. Note also that in the first case, the EN-CN interface defines an LSP region boundary (see [MPLS-HIER]). In the second case, this boundary may be found within the network. D.Papadimitriou et al. - Expires August 2004 3 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-01.txt February 2004 As defined in [MPLS-HIER], a (data plane) switching layer is mapped to a (control plane) LSP region. Following this approach, TE links have been extended to non adjacent nodes by the introduction of Forwarding Adjacency (FA). Using this concept, a node may (under the control of its local policy configuration) advertise an LSP as a TE link into the same IGP routing instance as the one that induces this LSP. Such a link is referred to as a Forwarding Adjacency (FA) and the corresponding LSP to a Forwarding Adjacency LSP (FA-LSP). Since the advertised entity appears as a TE link, both end-point nodes of the FA-LSP must belong to the same OSPF area/IS-IS level. Afterwards, OSPF/IS-IS floods the link-state information about FAs just as it floods the information about any other TE link. This allows other nodes to use FAs as any other TE links for path computation purposes. At the EN-CN interface, the signaling channel may be out-of-band or in-band. In the latter case, several implementation choices are possible for the GMPLS signaling message channel: 1) specific Ethertype that allows discrimination between data and control traffic (that may be directed towards a dedicated destination MAC address), 2) dedicated VLAN for the control traffic, and 3) use of a dedicated destination MAC address for reaching the peering GMPLS controller. Nevertheless, the signaling transport implementation for the UNI MUST be strictly independent of the signaling transport mechanism used between peering GMPLS nodes. 3.2 GMPLS E-NNI When two core networks (1 and 2) are interconnected by two core nodes (CN1 and CN2) they define an external network-network interface, as illustrated by the following (simplified) topology: B---C F---G / \ / \ --A CN1---CN2 H-- \ / \ / E---D J---I In this topology, [A,B], [A,E] and their network 2 counter part are [L2SC,Y] TE links, [C,CN1], [D,CN1] and their network 2 counter part are [Y,L2SC] TE Links, and [CN1,CN2] is a [L2SC,L2SC] TE link. Therefore the Ethernet LSP that can be setup between node A (ingress) and node H (egress) may be constituted by 2 FA LSPs interconnected by the [L2SC,L2SC] TE link defined at the E-NNI. Applicability of GMPLS RSVP-TE signaling [RFC-3473] at the E-NNI is detailed in [GMPLS-ENNI]. 4. Addressing Addressing follows the rules defined in [GMPLS-UNI] and [GMPLS- ENNI]. As defined in these documents, the SESSION and D.Papadimitriou et al. - Expires August 2004 4 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-01.txt February 2004 SENDER_TEMPLATE/FILTER_SPEC objects are end-to-end significant i.e. a single end-to-end RSVP session is defined (in compliance with the RSVP paradigm). 5. Signaling Layer-2 LSP setup, notification, graceful and non-graceful deletion procedures follow [RFC-3471], [RFC-3473], [GMPLS-UNI] and [GMPLS- ENNI]. Signaling mechanisms applies to both uni- and bi-directional Layer-2 LSP. 5.1 Layer-2 Label Request The GENERALIZED_LABEL_REQUEST object uses the following parameters: the LSP Encoding Type is set to 2 (Ethernet), the Switching Type is set to 51 (L2SC). Translation of the LSP request at the edge CN can make use of one of the following method: 1) direct end-to-end LSP [RFC-3473], 2) LSP splicing [RFC-3473] and stitching, 3) LSP nesting into a FA-LSP [MPLS-HIER]. Note that techniques for automated LSP stitching are described in [MPLS-IRN]. Also, in the overlay context, Ethernet LSPs nesting into a FA-LSP can be used when the ingress/egress edge CN provides (flow) multiplexing capabilities. 5.2 Layer-2 Label Layer-2 LABEL object follows the generic rules of the GENERALIZED_ LABEL object defined in [RFC-3471] for C-Type 2. This is a 32-bit label value that represents either the port or the interface over which the native Ethernet service access the network. Other semantics are possible for the Layer-2 labels as long as the assigning node fulfils the unicity requirement for the label(s) assigned to a given requestor. In the overlay context, the assigning node (and requesting node) are either the ingress EN (and CN, respectively), or the egress CN (and EN, respectively). Bi-directional Layer-2 Ethernet LSPs are indicated by the presence of an upstream label in the Path message. Upstream label assignment follows the format of the UPSTREAM LABEL object and the procedures defined in [RFC-3473]. 5.3 Bandwidth Encoding Specifics The requested bandwidth for Layer-2 Ethernet LSPs is encoded in the SENDER_TSPEC and FLOWSPEC objects as defined in [RFC-3471]. The unit is bytes per second. These values are set in the Peak Data Rate (PDR) field of Intserv objects [RFC-2210]. For instance, a 1Gbps Ethernet LSP will have a PDR value of 0x4CEE6B28. More generally, LSP Bandwidth increments of 1 Mbps (at least) are to be provided. D.Papadimitriou et al. - Expires August 2004 5 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-01.txt February 2004 [RFC3471] gives a definition of values to be used for Ethernet signal types. Note that the present document does not assume any specific restriction or constraint from the support of different Ethernet payload adaptation capabilities. 6. Explicit Routing 6.1 EXPLICIT_ROUTE Object (ERO) Processing EXPLICIT ROUTE objects can make use of the subobjects defined in [RFC-3209] for numbered interfaces and TE links, [RFC-3477] for unnumbered interfaces and TE links and finally [RFC-3473] for labels. EXPLICIT ROUTE object processing MUST follow the procedures defined in [RFC-3209], [RFC-3473], [RFC-3477], and [GMPLS-UNI] and [GMPLS-ENNI] when applicable. 6.2 RECORD_ROUTE Object (RRO) Processing RECORD ROUTE objects can make use of the subobjects defined in [RFC-3209] for numbered interfaces, TE links and labels, [RFC-3477] for unnumbered interfaces and TE links. RECORD ROUTE object processing MUST follow the procedures defined in [RFC-3209], [RFC- 3473], [RFC-3477], and [GMPLS-UNI], [GMPLS-ENNI] when applicable. 6.3 Explicit Label Control Explicit label control refers to the label identification of the egress TE link. An ingress node may include an ERO for which the last hop includes node-ID of the egress node and any other sub- objects necessary to uniquely identify the TE link, component link and labels for the requested Ethernet LSP. Note: in the overlay context, when the L-bit is set, this last-hop may be the only hop included in the ERO (see [GMPLS-UNI]). 7. Security considerations In its current version, this memo does not introduce new security consideration from the ones already detailed in [RFC-3471] and [RFc- 3473]. 8. References 8.1 Normative References [GMPLS-ARCH] E.Mannie (Editor) et al., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", Internet Draft, Work in Progress, draft-ietf-ccamp-gmpls-architecture- 07.txt, May 2003. [GMPLS-UNI] G.Swallow et al., "GMPLS UNI: RSVP Support for the Overlay Model," Internet Draft, Work in Progress, draft- ietf-ccamp-gmpls-overlay-02.txt, October 2003. D.Papadimitriou et al. - Expires August 2004 6 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-01.txt February 2004 [GMPLS-RTG] K.Kompella (Editor), Y.Rekhter (Editor) et al. "Routing Extensions in Support of Generalized MPLS", Internet Draft, Work in Progress, draft-ietf-ccamp- gmpls-routing-09.txt, October 2003. [MPLS-HIER] K.Kompella and Y.Rekhter, "LSP Hierarchy with Generalized MPLS TE", Internet Draft, Work in Progress, draft-ietf-mpls-lsp-hierarchy-08.txt, September 2002. [MPLS-BDL] K.Kompella, Y.Rekhter and Lou Berger, "Link Bundling in MPLS Traffic Engineering", Internet Draft, Work in Progress, draft-ietf-mpls-bundle-04.txt, July 2002. [RFC-2205] R.Braden (Editor).et al, "Resource ReserVation Protocol -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC-2210] J.Wroclawski, "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997. [RFC-2961] L.Berger et al., "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001 [RFC-3209] D.Awduche et al., "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC-3471] L.Berger (Editor) et al., "Generalized Multi-Protocol Label Switching (GMPLS) - Signaling Functional Description," RFC 3471, January 2003. [RFC-3473] L.Berger (Editor) et al., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions," RFC 3473, January 2003. [RFC-3477] K.Kompella and Y.Rekhter, "Signalling Unnumbered Links in Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)," RFC 3477, January 2003. 8.2 Informative References [MPLS-IRN] A.Ayyangar et al., "Inter-region MPLS Traffic Engineering," Internet Draft, Work in progress, draft- ayyangar-inter-region-te-01.txt, October 2003. 9. Acknowledgments The authors would like to acknowledge Emmanuel Dotaro for the fruitful discussions and Mastuura Nobuaki for his useful comments to this document. D.Papadimitriou et al. - Expires August 2004 7 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-01.txt February 2004 10. Author's addresses Dimitri Papadimitriou (Alcatel) Francis Wellensplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240 8491 EMail: dimitri.papadimitriou@alcatel.be Deborah Brungard (AT&T) Rm. D1-3C22 - 200 S. Laurel Ave. Middletown, NJ 07748, USA Phone: +1 732 420 1573 EMail: dbrungard@att.com Martin Vigoureux (Alcatel) Route de Nozay, 91461 Marcoussis cedex, France Phone: +33 1 6963 1852 EMail: martin.vigoureux@alcatel.fr D.Papadimitriou et al. - Expires August 2004 8 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-01.txt February 2004 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." D.Papadimitriou et al. - Expires August 2004 9