One document matched: draft-papadimitriou-ccamp-gmpls-l2sc-lsp-01.txt
Differences from draft-papadimitriou-ccamp-gmpls-l2sc-lsp-00.txt
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
| PAFTECH AB 2003-2026 | 2026-04-23 06:14:08 |