One document matched: draft-papadimitriou-ccamp-gmpls-l2sc-lsp-00.txt
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
| PAFTECH AB 2003-2026 | 2026-04-24 01:17:33 |