Beruflich Dokumente
Kultur Dokumente
Berger
Request for Comments: 6004 LabN
Category: Standards Track D. Fedyk
ISSN: 2070-1721 Alcatel-Lucent
October 2010
Abstract
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Table of Contents
1. Introduction ....................................................3
1.1. Overview ...................................................3
1.2. Conventions Used in This Document ..........................4
2. Common Signaling Support ........................................5
2.1. Ethernet Endpoint Identification ...........................5
2.1.1. Endpoint ID TLV .....................................5
2.1.1.1. Procedures .................................6
2.2. Connection Identification ..................................6
2.2.1. Procedures ..........................................6
2.3. Traffic Parameters .........................................7
2.3.1. L2 Control Protocol TLV .............................7
2.4. Bundling and VLAN Identification ...........................9
3. EPL Service .....................................................9
3.1. EPL Service Parameters .....................................9
4. EVPL Service ...................................................10
4.1. EVPL Generalized Label Format .............................10
4.2. Egress VLAN ID Control and VLAN ID Preservation ...........11
4.3. Single Call - Single LSP ..................................11
4.4. Single Call - Multiple LSPs ...............................11
5. IANA Considerations ............................................12
5.1. Endpoint ID Attributes TLV ................................12
5.2. Line LSP Encoding .........................................12
5.3. Ethernet Virtual Private Line (EVPL) Switching Type .......12
6. Security Considerations ........................................13
7. References .....................................................13
7.1. Normative References ......................................13
7.2. Informative References ....................................14
Acknowledgments ...................................................14
1. Introduction
[MEF6] and [G.8011] are focused on service interfaces and not the
underlying technology used to support the service. For example,
[G.8011] refers to the defined services being transported over one of
several possible "server layers". This document focuses on the types
of switching that may directly support these services and provides a
method for GMPLS-based control of such switching technologies. This
document defines the GMPLS extensions needed to support such
switching, but does not define the UNI or External NNI (E-NNI)
reference points. See [RFC6005] for a description of the UNI
reference point. This document makes use of the traffic parameters
defined in [RFC6003] and the generic extensions defined in [RFC6002].
1.1. Overview
LSPs, and support for such LSPs is included in the scope of this
document. There is no such clear correspondence between E-LAN/MP2MP
service and GMPLS TE LSPs. Although, it is possible to emulate this
service using multiple P2P or P2MP TE LSPs, the definition of support
for MP2MP service is left for future study and is not addressed in
this document.
- Endpoint identifiers
- Connection identifiers
- Traffic parameters (see [RFC6003])
- Bundling / VLAN IDs map (EVPL only)
- VLAN ID Preservation (EVPL only)
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 [RFC2119].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (30) | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint ID |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Endpoint ID
2.1.1.1. Procedures
2.2.1. Procedures
- Bandwidth Profile
- VLAN Class of Service (CoS) Preservation
- Layer 2 Control Protocol (L2CP) Processing (see Section 2.3.1)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=3 | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IL2CP | EL2CP | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved: 24 bits
3. EPL Service
Signaling for the EPL service types only differ in the LSP Encoding
Type used. The LSP Encoding Type used for each are:
4. EVPL Service
The relevant [RFC3471] parameter values that MUST be used for EVPL
connections are:
LSPs that provide EVPL service type Ethernet switching MUST use the
EVPL Generalized Label Format per Section 4.1, and the Generalized
Channel_Set Label Objects per [RFC6002]. A notable implication of
bundled EVPL services and carrying multiple VLAN IDs is that a Path
message may grow to be larger than a single (fragmented or non-
fragmented) IP packet. The basic approach to solving this is to
allow for multiple LSPs which are associated with a single Call, see
Section 2.2. The specifics of this approach are describe below in
Section 4.4.
The format for the Generalized Label (Label Type value 2) used with
EVPL services is:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd | VLAN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved: 4 bits
A VLAN identifier.
When an EVPL service is not configured for both bundling and VLAN ID
preservation, [MEF6] allows VLAN ID mapping. In particular, the
single VLAN ID used at the incoming interface of the ingress may be
mapped to a different VLAN ID at the outgoing interface at the egress
UNI. Such mapping MUST be requested and signaled based on the
explicit label control mechanism defined in [RFC3473] and clarified
in [RFC4003].
When the explicit label control mechanism is not used, VLAN IDs MUST
be preserved, i.e., not modified, across an LSP.
When using multiple LSPs, all LSPs associated with the same Call/EVPL
connection MUST be signaled with the same LSP objects with the
exception of the SENDER_TEMPLATE, SESSION, and label-related objects.
All such LSPs SHOULD share resources. When using multiple LSPs, VLAN
IDs MAY be added to the EVPL connection using either a new LSP or
make-before-break procedures, see [RFC3209]. Make-before-break
procedures on individual LSPs SHOULD be used to remove VLAN IDs.
5. IANA Considerations
IANA has assigned new values for namespaces defined in this document
and summarized in this section. The registries are available from
http://www.iana.org.
IANA has made the following assignment in the "Call Attributes TLV"
section of the "RSVP Parameters" registry.
IANA has made the following assignment in the "LSP Encoding Types"
section of the "GMPLS Signaling Parameters" registry.
6. Security Considerations
This document introduces new message object formats for use in GMPLS
signaling [RFC3473]. It does not introduce any new signaling
messages, nor change the relationship between Label Switching Routers
(LSRs) that are adjacent in the control plane. As such, this
document introduces no additional security considerations to those
discussed in [RFC3473].
7. References
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
Acknowledgments
The authors would like to thank Evelyne Roch, Stephen Shew, and Yoav
Cohen for their valuable comments.
Authors' Addresses
Lou Berger
LabN Consulting, L.L.C.
Phone: +1-301-468-9228
EMail: lberger@labn.net
Don Fedyk
Alcatel-Lucent
Groton, MA 01450
Phone: +1-978-467-5645
EMail: donald.fedyk@alcatel-lucent.com