[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

CCAMP Working Group                                     D.Papadimitriou
Internet Draft                                                (Alcatel)
Expiration Date: August 2004


                                                          February 2004

               Generalized MPLS (GMPLS) RSVP-TE Signaling
            in support of Layer-2 Label Switched Paths (LSP)


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

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at


   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",
   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-

   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].


   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.


   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-

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

   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

D.Papadimitriou et al. - Expires August 2004                         9

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/