draft-ietf-ccamp-gmpls-ether-svcs-01.txt   draft-ietf-ccamp-gmpls-ether-svcs-02.txt 
Internet Draft Lou Berger (LabN) Internet Draft Lou Berger (LabN)
Updates: 3471, 3473, 3945, 4202
Category: Standards Track Don Fedyk (Nortel) Category: Standards Track Don Fedyk (Nortel)
Expiration Date: January 14, 2009 Expiration Date: February 8, 2009
July 14, 2008 August 8, 2008
Generalized MPLS (GMPLS) Support For Metro Ethernet Forum Generalized MPLS (GMPLS) Support For Metro Ethernet Forum
and G.8011 Ethernet Service Switching and G.8011 Ethernet Service Switching
draft-ietf-ccamp-gmpls-ether-svcs-01.txt draft-ietf-ccamp-gmpls-ether-svcs-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on January 14, 2009. This Internet-Draft will expire on February 8, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document describes a method for controlling two specific types This document describes a method for controlling two specific types
of Ethernet switching via Generalized Multi-Protocol Label Switching of Ethernet switching via Generalized Multi-Protocol Label Switching
(GMPLS). This document supports the types of switching required to (GMPLS). This document supports the types of switching implied by
implied by the Ethernet services that have been defined in the the Ethernet services that have been defined in the context of the
context of the Metro Ethernet Forum (MEF) and International Metro Ethernet Forum (MEF) and International Telecommunication Union
Telecommunication Union (ITU) G.8011. Specifically, switching in (ITU) G.8011. Specifically, switching in support of Ethernet private
support of Ethernet private line service and Ethernet virtual private line service and Ethernet virtual private line service. Support for
line service. Support for MEF and ITU defined parameters are also MEF and ITU defined parameters are also covered. Some of the
covered. Some of the extensions defined in this document are generic extensions defined in this document are generic in nature and not
in nature and not specific to Ethernet. specific to Ethernet.
Table of Contents Table of Contents
1 Introduction .............................................. 3 1 Introduction .............................................. 3
1.1 Overview .................................................. 3 1.1 Overview .................................................. 3
1.2 Conventions used in this document ......................... 5 1.2 Conventions used in this document ......................... 5
2 Common Signaling Support .................................. 5 2 Common Signaling Support .................................. 5
2.1 Ethernet Endpoint Identification .......................... 5 2.1 Ethernet Endpoint Identification .......................... 5
2.1.1 Endpoint ID TLV ........................................... 6 2.1.1 Endpoint ID TLV ........................................... 6
2.2 Connection Identification ................................. 7 2.2 Connection Identification ................................. 7
skipping to change at page 2, line 25 skipping to change at page 2, line 25
2.3 Traffic Parameters ........................................ 7 2.3 Traffic Parameters ........................................ 7
2.3.1 L2 Control Protocol TLV ................................... 8 2.3.1 L2 Control Protocol TLV ................................... 8
2.4 Bundling and VLAN Identification .......................... 9 2.4 Bundling and VLAN Identification .......................... 9
3 EPL Service ............................................... 9 3 EPL Service ............................................... 9
3.1 EPL Service Parameters .................................... 10 3.1 EPL Service Parameters .................................... 10
4 EVPL Service .............................................. 10 4 EVPL Service .............................................. 10
4.1 EVPL Generalized Label Format ............................. 11 4.1 EVPL Generalized Label Format ............................. 11
4.2 Egress VLAN ID Control and VLAN ID preservation ........... 11 4.2 Egress VLAN ID Control and VLAN ID preservation ........... 11
4.3 Single Call - Single LSP .................................. 12 4.3 Single Call - Single LSP .................................. 12
4.4 Single Call - Multiple LSPs ............................... 12 4.4 Single Call - Multiple LSPs ............................... 12
5 Generic GMPLS Extensions .................................. 12 5 IANA Considerations ....................................... 12
5.1 Data Channel Switching .................................... 13 5.1 Endpoint ID Attributes TLV ................................ 13
5.2 Generalized Channel_Set Label Related Formats ............. 13 5.2 Line LSP Encoding ......................................... 13
5.2.1 Generalized Channel_Set LABEL_REQUEST Object .............. 13 6 Security Considerations ................................... 13
5.2.2 Generalized Channel_Set LABEL Object ...................... 14 7 References ................................................ 13
5.2.3 Other Label related Objects ............................... 16 7.1 Normative References ...................................... 13
6 IANA Considerations ....................................... 17 7.2 Informative References .................................... 14
6.1 Endpoint ID Attributes TLV ................................ 17 8 Acknowledgments ........................................... 15
6.2 Line LSP Encoding ......................................... 17 9 Author's Addresses ........................................ 15
6.3 Data Channel Switching Type ............................... 17 10 Full Copyright Statement .................................. 16
6.4 Generalized Channel_Set LABEL_REQUEST Object .............. 18 11 Intellectual Property ..................................... 16
6.5 Generalized Channel_Set LABEL Object ...................... 18
7 Security Considerations ................................... 18
8 References ................................................ 19
8.1 Normative References ...................................... 19
8.2 Informative References .................................... 20
9 Acknowledgments ........................................... 21
10 Author's Addresses ........................................ 21
11 Full Copyright Statement .................................. 21
12 Intellectual Property ..................................... 22
1. Introduction 1. Introduction
[MEF6] and [G.8011] provide parallel frameworks for defining network- [MEF6] and [G.8011] provide parallel frameworks for defining network-
oriented characteristics of Ethernet services in transport networks. oriented characteristics of Ethernet services in transport networks.
The framework discusses general Ethernet connection characteristics, The framework discusses general Ethernet connection characteristics,
Ethernet User-Network Interfaces (UNIs) and Ethernet Network-Network Ethernet User-Network Interfaces (UNIs) and Ethernet Network-Network
Interfaces (NNIs). Within this framework, [G.8011.1] defines the Interfaces (NNIs). Within this framework, [G.8011.1] defines the
Ethernet Private Line (EPL) service and [G.8011.2] defines the Ethernet Private Line (EPL) service and [G.8011.2] defines the
Ethernet Virtual Private Line (EVPL) service. [MEF6] covers both Ethernet Virtual Private Line (EVPL) service. [MEF6] covers both
skipping to change at page 3, line 27 skipping to change at page 3, line 27
[MEF6] and [G.8011] are focused on service interfaces and not the [MEF6] and [G.8011] are focused on service interfaces and not the
underlying technology used to support the service. For example, underlying technology used to support the service. For example,
[G.8011] refers to the defined services being transported over one of [G.8011] refers to the defined services being transported over one of
several possible "server layers". This document focuses on the types several possible "server layers". This document focuses on the types
of switching that may directly support these services and provides a of switching that may directly support these services and provides a
method for GMPLS based control of such switching technologies. This method for GMPLS based control of such switching technologies. This
document defines the GMPLS extensions needed to support such document defines the GMPLS extensions needed to support such
switching, but does not define the UNI or External NNI (E-NNI) switching, but does not define the UNI or External NNI (E-NNI)
reference points. See [GMPLS-MEF-UNI] for a description of the UNI reference points. See [GMPLS-MEF-UNI] for a description of the UNI
reference point. This document makes use of the traffic parameters reference point. This document makes use of the traffic parameters
defined in [ETH-TRAFFIC]. defined in [ETH-TRAFFIC] and the generic extensions defined in
[GMPLS-EXT].
Some of the extensions defined in this document are generic in nature
and not specific to Ethernet, or [MEF6] and [G.8011] related
switching. [AUTHORS' NOTE: These extensions are presented in a
separate section and may be split into their own document as this
work progresses.]
1.1. Overview 1.1. Overview
This document uses a largely common approach to supporting the This document uses a common approach to supporting the switching
switching implied by the Ethernet services defined in [MEF6], implied by the Ethernet services defined in [MEF6], [G.8011.1] and
[G.8011.1] and [G.8011.2]. The approach builds on standard GMPLS [G.8011.2]. The approach builds on standard GMPLS mechanisms to
mechanisms to deliver the required control capabilities. This deliver the required control capabilities. This document reuses the
document reuses the GMPLS mechanisms specified in [RFC3473] and GMPLS mechanisms specified in [RFC3473] and [RFC4974]. The document
[RFC4974]. The document also expands expands the set of signaling uses the extensions defined in [GMPLS-EXT].
parameters in a fashion consistent with existing GMPLS signaling.
[AUTHORS' NOTE: As mentioned above, several extensions defined in
this document are generic in nature and may be moved into their own
document as this work progresses.]
Two types of connectivity between Ethernet endpoints are defined in Two types of connectivity between Ethernet endpoints are defined in
[MEF6] and [G.8011]: point-to-point (P2P) and multipoint-to- [MEF6] and [G.8011]: point-to-point (P2P) and multipoint-to-
multipoint (MP2MP). [MEF6] uses the term Ethernet Line (E-line) to multipoint (MP2MP). [MEF6] uses the term Ethernet Line (E-line) to
refer to point-to-point virtual connections, and Ethernet LAN (E-LAN) refer to point-to-point virtual connections, and Ethernet LAN (E-LAN)
to refer to multipoint-to-multipoint virtual connections. [G.8011] to refer to multipoint-to-multipoint virtual connections. [G.8011]
also identifies point-to-multipoint (P2MP) as an area for "further also identifies point-to-multipoint (P2MP) as an area for "further
study." Within the context of GMPLS, support is defined for point- study." Within the context of GMPLS, support is defined for point-
to-point unidirectional and bidirectional TE Label Switched Paths to-point unidirectional and bidirectional TE Label Switched Paths
(LSPs), see [RFC3473], and unidirectional point-to-multipoint TE (LSPs), see [RFC3473], and unidirectional point-to-multipoint TE
skipping to change at page 5, line 4 skipping to change at page 4, line 42
supported in signaling include: supported in signaling include:
- Endpoint identifiers - Endpoint identifiers
- Connection identifiers - Connection identifiers
- Traffic parameters (see [ETH-TRAFFIC]) - Traffic parameters (see [ETH-TRAFFIC])
- Bundling / VLAN IDs map (EVPL only) - Bundling / VLAN IDs map (EVPL only)
- VLAN ID Preservation (EVPL only) - VLAN ID Preservation (EVPL only)
Common procedures used to support Ethernet LSPs are described in Common procedures used to support Ethernet LSPs are described in
Section 2 of this document. Procedures related to signaling Section 2 of this document. Procedures related to signaling
switching in support of EPL services are described in Section 3. switching in support of EPL services are described in Section 3.
Procedures related to signaling switching in support of EVPL services Procedures related to signaling switching in support of EVPL services
are described in Section 4. Section 5 covers the generic GMPLS are described in Section 4.
extensions proposed by this document.
1.2. Conventions used in this document 1.2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Common Signaling Support 2. Common Signaling Support
This section describes the common mechanisms for supporting GMPLS This section describes the common mechanisms for supporting GMPLS
skipping to change at page 10, line 19 skipping to change at page 10, line 19
EPL Service LSP Encoding Type EPL Service LSP Encoding Type
----------- ----------------- ----------- -----------------
Type 1/MEF Ethernet (2) [RFC3471] Type 1/MEF Ethernet (2) [RFC3471]
Type 2 Line (e.g., 8B/10B) (TBA by IANA) Type 2 Line (e.g., 8B/10B) (TBA by IANA)
The other LSP parameters specific to EPL Service are: The other LSP parameters specific to EPL Service are:
Parameter Value Parameter Value
-------------- ----- -------------- -----
Switching Type DCSC (See Section 5.2) Switching Type DCSC [GMPLS-EXT]
G-PID Ethernet (33) [RFC3471] G-PID Ethernet (33) [RFC3471]
The parameters defined in this section MUST be used when establishing The parameters defined in this section MUST be used when establishing
and controlling LSPs that provide EPL service type Ethernet and controlling LSPs that provide EPL service type Ethernet
switching. The procedures defined in Section 2 and the other switching. The procedures defined in Section 2 and the other
procedures defined in [RFC3473] for the establishment and management procedures defined in [RFC3473] for the establishment and management
of bidirectional LSPs MUST be followed when establishing and of bidirectional LSPs MUST be followed when establishing and
controlling LSPs that provide EPL service type Ethernet switching. controlling LSPs that provide EPL service type Ethernet switching.
4. EVPL Service 4. EVPL Service
skipping to change at page 10, line 45 skipping to change at page 10, line 45
or unbundled. Independent of the different forms, LSPs supporting or unbundled. Independent of the different forms, LSPs supporting
EVPL Ethernet type switching are signaled using the same mechanisms EVPL Ethernet type switching are signaled using the same mechanisms
to communicate the one or more VLAN IDs associated with a particular to communicate the one or more VLAN IDs associated with a particular
LSP (Ethernet connection). LSP (Ethernet connection).
The relevant [RFC3471] parameter values that MUST be used for EVPL The relevant [RFC3471] parameter values that MUST be used for EVPL
connections are: connections are:
Parameter Value Parameter Value
-------------- ----- -------------- -----
Switching Type TBD [NOTE: use of L2SC under discussion] Switching Type TBD [NOTE: under discussion]
LSP Encoding Type Ethernet (2) LSP Encoding Type Ethernet (2)
G-PID Ethernet (33) G-PID Ethernet (33)
As with EPL, the procedures defined in Section 2 and the other As with EPL, the procedures defined in Section 2 and the other
procedures defined in [RFC3473] for the establishment and management procedures defined in [RFC3473] for the establishment and management
of bidirectional LSPs MUST be followed when establishing and of bidirectional LSPs MUST be followed when establishing and
controlling LSPs that provide EVPL service type Ethernet switching. controlling LSPs that provide EVPL service type Ethernet switching.
LSPs that provide EVPL service type Ethernet switching MUST use the LSPs that provide EVPL service type Ethernet switching MUST use the
EVPL Generalized Label Format per Section 4.1, and the Generalized EVPL Generalized Label Format per Section 4.1, and the Generalized
Channel_Set Label Objects per Section 5.2. A notable implication of Channel_Set Label Objects per [GMPLS-EXT]. A notable implication of
bundled EVPL services and carrying multiple VLAN IDs is that a Path bundled EVPL services and carrying multiple VLAN IDs is that a Path
message may grow to be larger than a single (fragmented or non- message may grow to be larger than a single (fragmented or non-
fragmented) IP packet. The basic approach to solving this is to fragmented) IP packet. The basic approach to solving this is to
allow for multiple LSPs which are associated with a single call, see 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 2.2. The specifics of this approach are describe below in
Section 4.4. Section 4.4.
4.1. EVPL Generalized Label Format 4.1. EVPL Generalized Label Format
Bundled EVPL services requires the use of a service specific label, Bundled EVPL services requires the use of a service specific label,
skipping to change at page 11, line 47 skipping to change at page 11, line 47
VLAN ID: 12 bits VLAN ID: 12 bits
A VLAN identifier. A VLAN identifier.
4.2. Egress VLAN ID Control and VLAN ID preservation 4.2. Egress VLAN ID Control and VLAN ID preservation
Per [MEF6], the mapping of the single VLAN ID used at the incoming Per [MEF6], the mapping of the single VLAN ID used at the incoming
interface of the ingress to a different VLAN ID at the outgoing interface of the ingress to a different VLAN ID at the outgoing
interface at the egress UNI is allowed for EVPL services that do not interface at the egress UNI is allowed for EVPL services that do not
support both bundling and VLAN ID preservation. Such a mapping MUST support either bundling and VLAN ID preservation. Such a mapping
be requested and signaled based on the explicit label control MUST be requested and signaled based on the explicit label control
mechanism defined in [RFC3473] and clarified in [RFC4003]. mechanism defined in [RFC3473] and clarified in [RFC4003].
When the explicit label control mechanism is not used, VLAN IDs MUST When the explicit label control mechanism is not used, VLAN IDs MUST
be preserved, i.e., not modified, across an LSP. be preserved, i.e., not modified, across an LSP.
4.3. Single Call - Single LSP 4.3. Single Call - Single LSP
For simplicity in management, a single LSP SHOULD be used for each For simplicity in management, a single LSP SHOULD be used for each
EVPL type LSP whose Path and Resv messages fit within a single EVPL type LSP whose Path and Resv messages fit within a single
unfragmented IP packet. This allows the reuse of all standard LSP unfragmented IP packet. This allows the reuse of all standard LSP
modification procedures. Of particular note is the modification of modification procedures. Of particular note is the modification of
the VLAN IDs associated with the Ethernet connection. Specifically, the VLAN IDs associated with the Ethernet connection. Specifically,
per Section 5.3, make-before-break procedures SHOULD be used to [GMPLS-EXT], make-before-break procedures SHOULD be used to modify
modify the Channel_Set LABEL object. the Channel_Set LABEL object.
4.4. Single Call - Multiple LSPs 4.4. Single Call - Multiple LSPs
Multiple LSPs MAY be used to support an EVPL service connection. All Multiple LSPs MAY be used to support an EVPL service connection. All
such LSPs MUST be established within the same call and follow call such LSPs MUST be established within the same call and follow call
related procedures, see Section 2.2. The primary purpose of multiple related procedures, see Section 2.2. The primary purpose of multiple
LSPs is to support the case where the related objects result in a LSPs is to support the case where the related objects result in a
Path message being larger than a single unfragmented IP packet. Path message being larger than a single unfragmented IP packet.
When using multiple LSPs, all LSPs associated with the same call / When using multiple LSPs, all LSPs associated with the same call /
EVPL connection MUST be signaled with the same LSP objects with the EVPL connection MUST be signaled with the same LSP objects with the
exception of the SENDER_TEMPLATE, SESSION and label related objects. exception of the SENDER_TEMPLATE, SESSION and label related objects.
All such LSPs SHOULD share resources. When using multiple LSPs, VLAN 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 IDs MAY be added to the EVPL connection using either a new LSP or
make-before-break procedures, see [RFC3209]. Make-before-break make-before-break procedures, see [RFC3209]. Make-before-break
procedures on individual LSPs SHOULD be used to remove VLAN IDs. procedures on individual LSPs SHOULD be used to remove VLAN IDs.
To change other service parameters it is necessary to resignal all To change other service parameters it is necessary to resignal all
LSPs associated with the call via make-before-break procedures. LSPs associated with the call via make-before-break procedures.
5. Generic GMPLS Extensions 5. IANA Considerations
This section presents extensions to GMPLS that, while motivated by
EPL and EVPL service, are generic in nature and may be useful to any
switching technology controlled via GMPLS.
[AUTHORS' NOTE: The extensions presented in this section and may be
split into one or more independent documents as this work
progresses.]
5.1. Data Channel Switching
Current GMPLS switching types are defined in [RFC3945] and [RFC3471]
and support switching at the packet (PSC), frame (L2SC), time-slot
(TDM), frequency (LSC) and fiber (FSC) granularities. One type of
switching that is not well represented in this current set switching
that takes all data received on an ingress port and switches it
through a network to an egress port. While there are similarities
between this level of switching and the "opaque single wavelength"
case described in Section 3.5 of [RFC4202], such port-to-port
switching is not limited to the optical switching technology implied
by the LSC type. Therefore, a new switching type is defined.
The new switching type is called Data Channel Switching Capable
(DCSC). (Port switching seems a more intuitive name, but it collides
with PSC so isn't used.) DCSC interfaces are able to support
switching of the whole digital channel presented on single channel
interfaces. Interfaces that inherently support multiple channels,
e.g., WDM and channelized TDM interfaces, are specifically excluded
from this type. Any interface that can be represented as a single
digital channel are included. Examples include concatenated TDM and
line encoded interfaces. Framed interfaces may also be included when
they support switching on an interface granularity.
DCSC is represented in GMPLS, see [RFC3471] and [RFC4202], using the
value TBA (by IANA).
Port labels, as defined in [RFC3471], SHOULD be used for LSPs
signaled using the DCSC Switching Type.
5.2. Generalized Channel_Set Label Related Formats
This section defines a new type of generalized label and updates
related objects. This section updates the label related definitions
of [RFC3473]. The ability to communicate more than one label as part
of the same LSP was motivated by the support for the communication of
one or more VLAN IDs, but the formats defined in this section are not
technology specific and may be useful for other switching
technologies.
5.2.1. Generalized Channel_Set LABEL_REQUEST Object
The Generalized Channel_Set LABEL_REQUEST object is used to indicate
that the Generalized Channel_Set LABEL Object is to be used with the
associated LSP. The format of the Generalized Channel_Set
LABEL_REQUEST object is the same as the Generalized LABEL_REQUEST
object and uses of C-Type of TBA.
5.2.2. Generalized Channel_Set LABEL Object
The Generalized Channel_Set LABEL Object communicates one or more
labels, all of which can be used equivalently in the data path
associated with a single LSP. The format of the Generalized
Channel_Set LABEL Object is based on the LABEL_SET object defined in
[RFC3473]. It differs from the the LABEL_SET object in that the full
set may be represented in a single object rather than the multiple
objects required by the [RFC3473] LABEL_SET object. The object MUST
be used on LSPs that use the Generalized Channel_Set LABEL_REQUEST
object. The object MUST be processed per [RFC3473]. Make-before-
break procedures, see [RFC3209], SHOULD be used when modifying the
Channel_Set LABEL object.
The format of the Generalized Channel_Set LABEL object is:
o eneralized Channel_Set LABEL object: Class = 16, C-Type = TBA (By
IANA)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel_Set Sub-Object 1 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel_Set Sub-Object N |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Channel_Set Sub-Object size is measured in bytes and MUST always
be a multiple of 4, and at least 4, and has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Num Subchannels | Label Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel 1 |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :
: : :
: : :
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel N |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Action: 8 bits
See [RFC3471] for definition of actions. Range actions SHOULD
be used when possible to minimize the size of the Channel_Set
LABEL Object.
Number of Subchannels: 10 bits
Indicates the number of subchannels carried in the sub-object.
When the number of subchannels required exceeds the limit of
the field, i.e., 1024, multiple Channel_Set Sub-Objects MUST be
used. Note that the size of the sub-object may result in a
Path message being larger than a single unfragmented IP packet.
See section 4.4 for an example of how this case may be handled.
A value of zero (0) has special meaning and MAY be used in
either the LABEL or UPSTREAM_LABEL object. A value of zero (0)
is used in a LABEL or UPSTREAM_LABEL object to indicate that
the subchannel(s) used in the corresponding (downstream or
upstream) direction MUST match the subchannel(s) carried in the
reverse directions label object. When value of zero (0) is
used, no Subchannels are included in the Channel_Set Sub-Object
and only one Channel_Set Sub-Object may be present. The zero
(0) value MUST NOT be used in both the LABEL and UPSTREAM_LABEL
object of the same LSP.
Label Type: 14 bits
See [RFC3473] for a description of this field.
Subchannel: Variable
See [RFC3471] for a description of this field. Note that this
field may not be 32 bit aligned.
Padding: Variable
Padding is used to ensure that the length of a Channel_Set Sub-
Object meets the multiple of 4 byte size requirement stated
above. The field is only required when the Subchannel field is
not 32 bit aligned and the number of included Subchannel fields
result in the Sub-Object not being 32 bit aligned.
The Padding field MUST be included when the number of bits
represented in all the Subchannel fields included in a
Generalized Channel_Set Sub-Object result in the Sub-Object not
being 32 bit aligned. When present, the Padding field MUST
have a length that results in the Sub-Object being 32 bit
aligned. When present, the Padding field MUST be set to a zero
(0) value on transmission and MUST be ignored on receipt.
These bits SHOULD be passed through unmodified by transit
nodes.
5.2.3. Other Label related Objects
The previous section introduces a new LABEL object. As such the
formats of the other label related objects are also impacted.
Processing of these objects is not modified and remain per their
respective specifications. The other label related objects are
defined in [RFC3473] and include:
- SUGGESTED_LABEL object
- LABEL_SET object
- ACCEPTABLE_LABEL_SET object
- UPSTREAM_LABEL object
- RECOVERY_LABEL object
6. IANA Considerations
IANA is requested to administer assignment of new values for IANA is requested to administer assignment of new values for
namespaces defined in this document and reviewed in this section. namespaces defined in this document and reviewed in this section.
6.1. Endpoint ID Attributes TLV 5.1. Endpoint ID Attributes TLV
Upon approval of this document, the IANA will make the assignment in Upon approval of this document, the IANA will make the assignment in
the "CALL_ATTRIBUTES TLV Space" section of the "RSVP TE Parameters" the "CALL_ATTRIBUTES TLV Space" section of the "RSVP TE Parameters"
registry located at http://www.iana.org/assignments/rsvp-te- registry located at http://www.iana.org/assignments/rsvp-te-
parameters: parameters:
Type Name Reference Type Name Reference
---- ----------- --------- ---- ----------- ---------
2* Endpoint ID [This document] 2* Endpoint ID [This document]
(*) Suggested value. (*) Suggested value.
6.2. Line LSP Encoding 5.2. Line LSP Encoding
Upon approval of this document, the IANA will make the assignment in Upon approval of this document, the IANA will make the assignment in
the "LSP Encoding Types" section of the "GMPLS Signaling Parameters" the "LSP Encoding Types" section of the "GMPLS Signaling Parameters"
registry located at http://www.iana.org/assignments/gmpls-sig- registry located at http://www.iana.org/assignments/gmpls-sig-
parameters: parameters:
Value Type Reference Value Type Reference
----- --------------------------- --------- ----- --------------------------- ---------
14* Line (e.g., 8B/10B) [This document] 14* Line (e.g., 8B/10B) [This document]
(*) Suggested value. (*) Suggested value.
6.3. Data Channel Switching Type 6. Security Considerations
Upon approval of this document, the IANA will make the assignment in
the "Switching Types" section of the "GMPLS Signaling Parameters"
registry located at http://www.iana.org/assignments/gmpls-sig-
parameters:
Value Type Reference
----- --------------------------- ---------
125* Data Channel Switching Capable (DCSC) [This document]
(*) Suggested value.
6.4. Generalized Channel_Set LABEL_REQUEST Object
Upon approval of this document, the IANA will make the assignment in
the "Class Names, Class Numbers, and Class Types" section of the
"RSVP PARAMETERS" registry located at
http://www.iana.org/assignments/rsvp-parameters.
A new class type for the existing LABEL_REQUEST Object class number
(19) with the following definition:
Class Types or C-Types:
5* Generalized Channel_Set [This document]
(*) Suggested value.
6.5. Generalized Channel_Set LABEL Object
Upon approval of this document, the IANA will make the assignment in
the "Class Names, Class Numbers, and Class Types" section of the
"RSVP PARAMETERS" registry located at
http://www.iana.org/assignments/rsvp-parameters.
A new class type for the existing RSVP_LABEL Object class number (16)
with the following definition:
Class Types or C-Types:
4* Generalized Channel_Set [This document]
(*) Suggested value.
7. Security Considerations
This document introduces new message object formats for use in GMPLS This document introduces new message object formats for use in GMPLS
signaling [RFC3473]. It does not introduce any new signaling signaling [RFC3473]. It does not introduce any new signaling
messages, nor change the relationship between LSRs that are adjacent messages, nor change the relationship between LSRs that are adjacent
in the control plane. As such, this document introduces no additional in the control plane. As such, this document introduces no additional
security considerations. See [RFC3473] for relevant security security considerations. See [RFC3473] for relevant security
considerations. considerations.
8. References 7. References
8.1. Normative References 7.1. Normative References
[ETH-TRAFFIC] Papadimitriou, D., "Ethernet Traffic Parameters," [ETH-TRAFFIC] Papadimitriou, D., "Ethernet Traffic Parameters,"
draft-ietf-ccamp-ethernet-traffic-parameters-05.txt, draft-ietf-ccamp-ethernet-traffic-parameters-05.txt,
Work in progress, July 12, 2008. Work in progress, July 12, 2008.
[GMPLS-EXT] Berger, L., Papadimitriou, P., Fedyk, D.,
"Generalized MPLS (GMPLS) Data Channel Switching
Capable (DCSC) and Channel Set Label Extensions",
draft-ietf-ccamp-gmpls-dcsc-channel-ext-00.txt,
Work in Progress, August 2008.
[GMPLS-MRN] Papadimitriou, D. et al, "Generalized Multi-Protocol [GMPLS-MRN] Papadimitriou, D. et al, "Generalized Multi-Protocol
Label Switching (GMPLS) Protocol Extensions for Label Switching (GMPLS) Protocol Extensions for
Multi-Layer and Multi-Region Networks (MLN/MRN)", Multi-Layer and Multi-Region Networks (MLN/MRN)",
draft-ietf-ccamp-gmpls-mln-extensions-02.txt, draft-ietf-ccamp-gmpls-mln-extensions-02.txt,
Work in progress, July 2008. Work in progress, July 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119. Requirement Levels," RFC 2119.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T.,
skipping to change at page 19, line 35 skipping to change at page 14, line 33
[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", Switching (GMPLS) Signaling Functional Description",
RFC 3471, January 2003. RFC 3471, January 2003.
[RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label [RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling - Resource ReserVation Switching (GMPLS) Signaling - Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003. RFC 3473, January 2003.
[RFC3945] Mannie, E., Editor, "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3945, October
2004.
[RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress [RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress
Control", RFC 4003, February 2005. Control", RFC 4003, February 2005.
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
Extensions in Support of Generalized Multi-Protocol
Label Switching (GMPLS)", RFC 4202, October 2005.
[4420BIS] Farrel, A., et al. "Encoding of Attributes for [4420BIS] Farrel, A., et al. "Encoding of Attributes for
Multiprotocol Label Switching (MPLS) Label Switched Multiprotocol Label Switching (MPLS) Label Switched
Path (LSP) Establishment Using Resource ReserVation Path (LSP) Establishment Using Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE)", Protocol-Traffic Engineering (RSVP-TE)",
draft-ietf-ccamp-rfc4420bis-03.txt, draft-ietf-ccamp-rfc4420bis-03.txt,
Work in progress, May 27, 2008, Work in progress, May 27, 2008,
[RFC4974] Papadimitriou, D., Farrel, A. "Generalized MPLS [RFC4974] Papadimitriou, D., Farrel, A. "Generalized MPLS
(GMPLS) RSVP-TE Signaling Extensions in support of Calls", (GMPLS) RSVP-TE Signaling Extensions in support of Calls",
RFC 4974, August 2007. RFC 4974, August 2007.
8.2. Informative References 7.2. Informative References
[G.8011] ITU-T G.8011/Y.1307, "Ethernet over Transport [G.8011] ITU-T G.8011/Y.1307, "Ethernet over Transport
Ethernet services framework", August 2004. Ethernet services framework", August 2004.
[G.8011.1] ITU-T G.G.8011.1/Y.1307.1, "Ethernet private [G.8011.1] ITU-T G.G.8011.1/Y.1307.1, "Ethernet private
line service", August 2004. line service", August 2004.
[G.8011.2] ITU-T G.8011.2/Y.1307.2, "Ethernet virtual [G.8011.2] ITU-T G.8011.2/Y.1307.2, "Ethernet virtual
private line service", September 2005. private line service", September 2005.
[GMPLS-MEF-UNI] Berger, L., Papadimitriou, P., Fedyk, D., [GMPLS-MEF-UNI] Berger, L., Papadimitriou, P., Fedyk, D.,
"Generalized MPLS (GMPLS) Support For Metro "Generalized MPLS (GMPLS) Support For Metro
Ethernet Forum and G.8011 User-Network Interface Ethernet Forum and G.8011 User-Network Interface
(UNI)", Work in Progress, (UNI)", Work in Progress,
draft-berger-ccamp-gmpls-mef-uni-02.txt, draft-ietf-ccamp-gmpls-mef-uni-01.txt,
February 2008. August 2008.
[MEF6] The Metro Ethernet Forum, "Ethernet Services [MEF6] The Metro Ethernet Forum, "Ethernet Services
[MEF10.1] The Metro Ethernet Forum, "Ethernet Services [MEF10.1] The Metro Ethernet Forum, "Ethernet Services
Attributes Phase 2", MEF 10.1, November 2006. Attributes Phase 2", MEF 10.1, November 2006.
[MEF11] The Metro Ethernet Forum , "User Network [MEF11] The Metro Ethernet Forum , "User Network
Interface (UNI) Requirements and Framework", Interface (UNI) Requirements and Framework",
MEF 11, November 2004. MEF 11, November 2004.
[RFC4875] Aggarwal, R., Papadimitriou, P., Yasukawa, S., [RFC4875] Aggarwal, R., Papadimitriou, P., Yasukawa, S.,
Eds, "Extensions to Resource Reservation Eds, "Extensions to Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) for Protocol - Traffic Engineering (RSVP-TE) for
Point-to-Multipoint TE Label Switched Paths Point-to-Multipoint TE Label Switched Paths
(LSPs)", RFC 4875, May 2007. (LSPs)", RFC 4875, May 2007.
9. Acknowledgments 8. Acknowledgments
The authors would like to thank Evelyne Roch and Stephen Shew for Dimitri Papadimitriou provided substantial textual contributions to
their valuable comments. this document and coauthored earlier versions of this document.
10. Author's Addresses The authors would like to thank Evelyne Roch, Stephen Shew, and Yoav
Cohen for their valuable comments.
9. Author's Addresses
Lou Berger Lou Berger
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
Phone: +1-301-468-9228 Phone: +1-301-468-9228
Email: lberger@labn.net Email: lberger@labn.net
Dimitri Papadimitriou
Alcatel Lucent
Francis Wellesplein 1,
B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491
Email: Dimitri.Papadimitriou@alcatel-lucent.be
Don Fedyk Don Fedyk
Nortel Networks Nortel Networks
600 Technology Park Drive 600 Technology Park Drive
Billerica, MA, 01821 Billerica, MA, 01821
Phone: +1-978-288-3041 Phone: +1-978-288-3041
Email: dwfedyk@nortel.com Email: dwfedyk@nortel.com
11. Full Copyright Statement 10. Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
12. Intellectual Property 11. Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology to pertain to the implementation or use of the technology
described in this document or the extent to which any license described in this document or the extent to which any license
under such rights might or might not be available; nor does it under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to rights such rights. Information on the procedures with respect to rights
in RFC documents can be found in BCP 78 and BCP 79. in RFC documents can be found in BCP 78 and BCP 79.
skipping to change at line 954 skipping to change at line 703
any copyrights, patents or patent applications, or other any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org. IETF at ietf-ipr@ietf.org.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is provided by the IETF Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA). Administrative Support Activity (IASA).
Generated on: Mon Jul 14 12:19:42 EDT 2008 Generated on: Fri Aug 8 09:53:58 EDT 2008
 End of changes. 34 change blocks. 
314 lines changed or deleted 63 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/