CCAMP Working Group D.Papadimitriou Internet Draft (Alcatel) Expiration Date: April 2004 D.Brungard (ATT) M.Vigoureux (Alcatel) October 2003 Generalized MPLS Signaling for Layer-2 Label Switched Paths (LSP) draft-papadimitriou-ccamp-gmpls-l2sc-lsp-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract Most efforts on Generalized MPLS (GMPLS) have been focused to environments of single switching capability devices e.g. one data plane layer covering either Packet LSPs or Circuit oriented LSPs (Sonet/SDH, OTH, etc.). Relatively few have been said about the GMPLS signaling capability to support Layer-2 Label Switched Paths (LSPs), and in particular native Ethernet LSPs. This document does not extend these capabilities but simply details their utilization in several network environments including overlays. As such, it may be referred to as detailing the applicability statements for GMPLS for Ethernet switching environments in support of various deployment scenarios, including the peer model and the overlay model (e.g. Generalized VPN (GVPN) and user-network interfaces). D.Papadimitriou et al. - April 2004 1 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-00.txt October 2003 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-OVERLAY] as well as [MPLS-HIER] and [MPLS-BDL]. The following abbreviations are used in this document: CN: Core node EN: Edge node FA: Forwarding Adjacency FSC: Fiber-Switch Capable HOVC: Higher order virtual container ISC: Interface Switching Capability 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, since so far, 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. In particular, the integration of packet and circuit switching technologies under a unified GMPLS control plane provides a unified control management approach for both provisioning resources and restoration techniques. While being introduced in [GMPLS-ARCH], [GMPLS-RTG] and [RFC-3471], the GMPLS capability to control L2SC TE links and Layer-2 LSPs have received little attention since so far. For instance, [RFC-3471] defines the possibility to have 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 performed on a particular link). In this memo, we will consider a Layer-2 LSP as LSP being established between L2SC interfaces. These interfaces are defined as being capable of recognizing frame/cell boundaries and D.Papadimitriou et al. - Expires April 2004 2 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-00.txt October 2003 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). 3. Context The reference network considered (but not restricted to) in this document is provided in [GMPLS-OVERLAY]. This network is constituted by a core network including core-nodes (CN) surrounded by edge nodes (EN) that forms 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. On the other hand, 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. Moreover, 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 as 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. In this context, at the EN-CN interface, signaling channel may be out-of-band or in-band. In the latter case, several implementation 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 following specification MUST be strictly independent of the signaling transport mechanism used between peering GMPLS nodes. 4. Addressing Addressing follows the rules defined in [GMPLS-OVERLAY]. The important point being that the SESSION and SENDER_TEMPLATE objects D.Papadimitriou et al. - Expires April 2004 3 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-00.txt October 2003 are end-to-end significant i.e. a single end-to-end RSVP session is defined (in compliance with the RSVP paradigm and the RSVP change process [RSVP-CHANGE]). 5. Signaling Layer-2 LSP setup, notification, graceful and non-graceful deletion procedures follow [RFC-3471], [RFC-3473] and [GMPLS-OVERLAY]. 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 an FA-LSP applies perfectly well 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. [RFC3471] gives a definition of values to be used for Ethernet signal types. Note that the present document does not assume any D.Papadimitriou et al. - Expires April 2004 4 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-00.txt October 2003 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 object 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-OVERLAY] 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-OVERLAY] 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-OVERLAY]). 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-OVERLAY] G.Swallow et al., "GMPLS RSVP Support for the Overlay Model," Internet Draft, Work in Progress, draft- ietf-ccamp-gmpls-overlay-01.txt, February 2003. [GMPLS-RTG] K.Kompella (Editor), Y.Rekhter (Editor) et al. D.Papadimitriou et al. - Expires April 2004 5 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-00.txt October 2003 "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. [RSVP-CHANGE] K.Kompella and J.P.Lang, "Procedures for Modifying RSVP," Internet Draft, Work in Progress, draft-kompella- rsvp-change-01.txt, June 03. 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-00.txt, June 2003. 9. Acknowledgments The authors would like to acknowledge Emmanuel Dotaro for the fruitful discussions. D.Papadimitriou et al. - Expires April 2004 6 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-00.txt October 2003 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 April 2004 7 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-00.txt October 2003 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 April 2004 8