draft-ietf-ccamp-gmpls-ether-svcs-00.txt   draft-ietf-ccamp-gmpls-ether-svcs-01.txt 
Internet Draft Lou Berger (LabN) Internet Draft Lou Berger (LabN)
Updates: 3471, 3473, 3945, 4202 Updates: 3471, 3473, 3945, 4202
Category: Standards Track Don Fedyk (Nortel) Category: Standards Track Don Fedyk (Nortel)
Expiration Date: October 14, 2008 Expiration Date: January 14, 2009
April 14, 2008 July 14, 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-00.txt draft-ietf-ccamp-gmpls-ether-svcs-01.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 37
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 October 14, 2008. This Internet-Draft will expire on January 14, 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 required to
skipping to change at page 2, line 26 skipping to change at page 2, line 26
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 Generic GMPLS Extensions .................................. 12
5.1 Notify Message Format ..................................... 13 5.1 Data Channel Switching .................................... 13
5.2 Data Channel Switching .................................... 13 5.2 Generalized Channel_Set Label Related Formats ............. 13
5.3 Generalized Channel_Set Label Related Formats ............. 14 5.2.1 Generalized Channel_Set LABEL_REQUEST Object .............. 13
5.3.1 Generalized Channel_Set LABEL_REQUEST Object .............. 14 5.2.2 Generalized Channel_Set LABEL Object ...................... 14
5.3.2 Generalized Channel_Set LABEL Object ...................... 14 5.2.3 Other Label related Objects ............................... 16
5.3.3 Other Label related Objects ............................... 17
6 IANA Considerations ....................................... 17 6 IANA Considerations ....................................... 17
6.1 Endpoint ID Attributes TLV ................................ 17 6.1 Endpoint ID Attributes TLV ................................ 17
6.2 Line LSP Encoding ......................................... 17 6.2 Line LSP Encoding ......................................... 17
6.3 Data Channel Switching Type ............................... 18 6.3 Data Channel Switching Type ............................... 17
6.4 Generalized Channel_Set LABEL_REQUEST Object .............. 18 6.4 Generalized Channel_Set LABEL_REQUEST Object .............. 18
6.5 Generalized Channel_Set LABEL Object ...................... 18 6.5 Generalized Channel_Set LABEL Object ...................... 18
7 Security Considerations ................................... 19 7 Security Considerations ................................... 18
8 References ................................................ 19 8 References ................................................ 19
8.1 Normative References ...................................... 19 8.1 Normative References ...................................... 19
8.2 Informative References .................................... 20 8.2 Informative References .................................... 20
9 Acknowledgments ........................................... 21 9 Acknowledgments ........................................... 21
10 Author's Addresses ........................................ 21 10 Author's Addresses ........................................ 21
11 Full Copyright Statement .................................. 21 11 Full Copyright Statement .................................. 21
12 Intellectual Property ..................................... 22 12 Intellectual Property ..................................... 22
1. Introduction 1. Introduction
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 [MEF-TRAFFIC]. defined in [ETH-TRAFFIC].
Some of the extensions defined in this document are generic in nature Some of the extensions defined in this document are generic in nature
and not specific to Ethernet, or [MEF6] and [G.8011] related and not specific to Ethernet, or [MEF6] and [G.8011] related
switching. [AUTHORS' NOTE: These extensions are presented in a switching. [AUTHORS' NOTE: These extensions are presented in a
separate section and may be split into their own document as this separate section and may be split into their own document as this
work progresses.] work progresses.]
1.1. Overview 1.1. Overview
This document uses a largely common approach to supporting the This document uses a largely common approach to supporting the
skipping to change at page 4, line 45 skipping to change at page 4, line 45
per connection. Other attributes are specific to a particular per connection. Other attributes are specific to a particular
connection, or must be consistent across the connection. The connection, or must be consistent across the connection. The
approach taken in this document to communicate these attributes is to approach taken in this document to communicate these attributes is to
exclude the static class of attributes from signaling. This class of exclude the static class of attributes from signaling. This class of
attributes will not be explicitly discussed in this document. The attributes will not be explicitly discussed in this document. The
other class of attributes are communicated via signaling and will be other class of attributes are communicated via signaling and will be
reviewed in the sections below. The major attributes that will be reviewed in the sections below. The major attributes that will be
supported in signaling include: supported in signaling include:
- Endpoint identifiers - Endpoint identifiers
- Connection identifiers - Connection identifiers
- Traffic parameters (see [MEF-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. Section 5 covers the generic GMPLS
extensions proposed by this document. extensions proposed by this document.
skipping to change at page 5, line 36 skipping to change at page 5, line 36
2.1. Ethernet Endpoint Identification 2.1. Ethernet Endpoint Identification
Ethernet endpoint identifiers, as they are defined in [G.8011] and Ethernet endpoint identifiers, as they are defined in [G.8011] and
[MEF10.1], differ significantly from the identifiers used by GMPLS. [MEF10.1], differ significantly from the identifiers used by GMPLS.
Specifically, the Ethernet endpoint identifiers are character based Specifically, the Ethernet endpoint identifiers are character based
as apposed to the GMPLS norm of being IP address based. as apposed to the GMPLS norm of being IP address based.
The approach taken by this document to address this disparity The approach taken by this document to address this disparity
leverages the solution used for connection identification, see leverages the solution used for connection identification, see
Section 2.2 and [RFC4974], and the LSP attributes object, see Section 2.2 and [RFC4974], and a new CALL_ATTRIBUTES TLV defined in
[RFC4420]. The solution makes use of the [RFC4974] short call ID, this document. The solution makes use of the [RFC4974] short call
and supports the Ethernet endpoint identifier much like [RFC4974] ID, and supports the Ethernet endpoint identifier much like [RFC4974]
supports the long call ID. That is, the SENDER_TEMPLATE and SESSION supports the long call ID. That is, the SENDER_TEMPLATE and SESSION
objects carry IP addresses and a short call ID, and long identifiers objects carry IP addresses and a short call ID, and long identifiers
are carried in the attributes object. As with the long call ID, the are carried in the attributes object. As with the long call ID, the
Ethernet endpoint identifier is typically only relevant at the Ethernet endpoint identifier is typically only relevant at the
ingress and egress nodes. ingress and egress nodes.
As defined below, the Ethernet endpoint identifier is carried in the As defined below, the Ethernet endpoint identifier is carried in the
LSP_ATTRIBUTES object in a new TLV. The new TLV is referred to as CALL_ATTRIBUTES object in a new TLV. The new TLV is referred to as
the Endpoint ID TLV. The processing of the Endpoint ID TLV parallels the Endpoint ID TLV. The processing of the Endpoint ID TLV parallels
the processing of the long call ID in [RFC4974]. This processing the processing of the long call ID in [RFC4974]. This processing
requires the inclusion of the LSP_ATTRIBUTES object in a Notify requires the inclusion of the CALL_ATTRIBUTES object in a Notify
message, see Section 5.1. message.
2.1.1. Endpoint ID TLV 2.1.1. Endpoint ID TLV
The Endpoint ID TLV follows the Attributes TLV format defined in The Endpoint ID TLV follows the Attributes TLV format defined in
[RFC4420]. The Endpoint ID TLV has uses the Type value of TBA (by [GMPLS-MRN]. The Endpoint ID TLV has the following format:
IANA).
The TLV has the following format:
0 1 2 3 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 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 (TBA) | Length (variable) | | Type (TBA) | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint ID | | Endpoint ID |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC4420] for a description of the Type and Length fields. Type and Length fields are defined in [GMPLS-MRN]. Note that as
Note that per [RFC4420], the Length field is set to the unpadded defined in [GMPLS-MRN], the Length field is set to length of the
length of the Endpoint ID field. whole TLV including the Type, Length and Endpoint ID fields.
Endpoint ID Endpoint ID
The Endpoint ID field is a variable length field that carries The Endpoint ID field is a variable size field that carries an
an endpoint identifier, see [MEF10.1] and [G.8011]. This field endpoint identifier, see [MEF10.1] and [G.8011]. This field
MUST be null padded as defined in [RFC4420]. MUST be null padded as defined in [GMPLS-MRN].
2.1.1.1. Procedures 2.1.1.1. Procedures
The use of the Endpoint ID TLV is required during call management. The use of the Endpoint ID TLV is required during call management.
When a call is established or torn down per [RFC4974], an When a call is established or torn down per [RFC4974], a
LSP_ATTRIBUTES object containing an Endpoint ID TLV MUST be included CALL_ATTRIBUTES object containing an Endpoint ID TLV MUST be included
in the Notify message along with the Long Call ID. in the Notify message along with the Long Call ID.
Short Call ID processing, including those procedures related to call Short Call ID processing, including those procedures related to call
and connection processing, is not modified by this document and MUST and connection processing, is not modified by this document and MUST
proceed according to [RFC4974]. proceed according to [RFC4974].
An LSP_ATTRIBUTES object containing an Endpoint ID TLV MAY be A CALL_ATTRIBUTES object containing an Endpoint ID TLV MAY be
included in the signaling messages of an LSP (connection) associated included in the signaling messages of an LSP (connection) associated
with an established call. Such objects are processed according to with an established call. Such objects are processed according to
[RFC4420]. [4420BIS].
Transit nodes supporting this document MUST propagate the Endpoint ID Transit nodes supporting this document MUST propagate the Endpoint ID
TLV without modification. TLV without modification.
2.2. Connection Identification 2.2. Connection Identification
Signaling for Ethernet connections follows the procedures defined in Signaling for Ethernet connections follows the procedures defined in
[RFC4974]. In particular the Call related mechanisms are reused to [RFC4974]. In particular the Call related mechanisms are reused to
support endpoint identification. In the context of Ethernet support endpoint identification. In the context of Ethernet
connections, a call only exists when one or more LSPs (connections in connections, a call only exists when one or more LSPs (connections in
skipping to change at page 7, line 38 skipping to change at page 7, line 37
establish a Call per the procedures defined in [RFC4974]. LSP establish a Call per the procedures defined in [RFC4974]. LSP
management, including removal and addition, then follows [RFC4974]. management, including removal and addition, then follows [RFC4974].
As stated in [RFC4974], once a Call is established the initiator As stated in [RFC4974], once a Call is established the initiator
SHOULD establish at least one Ethernet LSP. Also, when the last LSP SHOULD establish at least one Ethernet LSP. Also, when the last LSP
associated with a Call is removed, the Call SHOULD be torn down per associated with a Call is removed, the Call SHOULD be torn down per
the procedures in [RFC4974]. the procedures in [RFC4974].
2.3. Traffic Parameters 2.3. Traffic Parameters
Several types of service attributes are carried in the traffic Several types of service attributes are carried in the traffic
parameters defined in [MEF-TRAFFIC]. These parameters are carried in parameters defined in [ETH-TRAFFIC]. These parameters are carried in
the FLOWSPEC and TSPEC objects as discussed in [MEF-TRAFFIC]. The the FLOWSPEC and TSPEC objects as discussed in [ETH-TRAFFIC]. The
service attributes that are carried are: service attributes that are carried are:
- Bandwidth Profile - Bandwidth Profile
- VLAN CoS Preservation - VLAN CoS Preservation
- Layer Two (L2) Control Protocol Processing (see Section 2.3.1) - Layer Two (L2) Control Protocol Processing (see Section 2.3.1)
Ethernet connections established according to this document MUST use Ethernet connections established according to this document MUST use
the traffic parameters defined in [MEF-TRAFFIC] in the FLOWSPEC and the traffic parameters defined in [ETH-TRAFFIC] in the FLOWSPEC and
TSPEC objects. TSPEC objects. Additionally, the Switching Granularity field of the
Ethernet SENDER_TSPEC object MUST be set to zero (0).
2.3.1. L2 Control Protocol TLV 2.3.1. L2 Control Protocol TLV
[MEF10.1], [8011.1] and [8011.2] define service attributes that [MEF10.1], [8011.1] and [8011.2] define service attributes that
impact the layer two (L2) control protocol processing at the ingress impact the layer two (L2) control protocol processing at the ingress
and egress. [MEF-TRAFFIC] does not define support for these service and egress. [ETH-TRAFFIC] does not define support for these service
attributes, but does allow the attributes to be carried in a TLV. attributes, but does allow the attributes to be carried in a TLV.
This section defines the L2 Control Protocol (L2CP) TLV to carry the This section defines the L2 Control Protocol (L2CP) TLV to carry the
L2 control protocol processing related service attributes. L2 control protocol processing related service attributes.
The format of the L2 Control Protocol (L2CP) TLV is as follows: The format of the L2 Control Protocol (L2CP) TLV is as follows:
0 1 2 3 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 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=2 | Length=4 | | Type=3 | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IL2CP | EL2CP | Reserved | | IL2CP | EL2CP | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [MEF-TRAFFIC] for a description of the Type and Length fields. See [ETH-TRAFFIC] for a description of the Type and Length fields.
Per [MEF-TRAFFIC], the Type field MUST be set to two (2), and the Per [ETH-TRAFFIC], the Type field MUST be set to two (2), and the
Length field MUST be set to four (4) for the L2CP TLV. Length field MUST be set to eight (8) for the L2CP TLV.
Ingress Layer 2 Control Processing (IL2CP): 4 bits Ingress Layer 2 Control Processing (IL2CP): 4 bits
This field controls processing of Layer 2 Control Protocols This field controls processing of Layer 2 Control Protocols
on a receiving interface. Valid usage is service specific, on a receiving interface. Valid usage is service specific,
see [MEF10.1], [8011.1] and [8011.2]. see [MEF10.1], [8011.1] and [8011.2].
Permitted values are: Permitted values are:
Value Description Reference Value Description Reference
skipping to change at page 9, line 22 skipping to change at page 9, line 22
3 None [8011.1] and [8011.2] 3 None [8011.1] and [8011.2]
4 Reserved 4 Reserved
Reserved: 24 bits Reserved: 24 bits
This field is reserved. It MUST be set to zero on transmission This field is reserved. It MUST be set to zero on transmission
and MUST be ignored on receipt. This field SHOULD be passed and MUST be ignored on receipt. This field SHOULD be passed
unmodified by transit nodes. unmodified by transit nodes.
Ethernet connections established according to this document MUST Ethernet connections established according to this document MUST
include the L2CP TLV in the [MEF-TRAFFIC] traffic parameters carried include the L2CP TLV in the [ETH-TRAFFIC] traffic parameters carried
in the FLOWSPEC and TSPEC objects. in the FLOWSPEC and TSPEC objects.
2.4. Bundling and VLAN Identification 2.4. Bundling and VLAN Identification
The control of bundling and listing of VLAN identifiers is only The control of bundling and listing of VLAN identifiers is only
supported for EVPL services. EVPL service specific details are supported for EVPL services. EVPL service specific details are
provided in Section 4. provided in Section 4.
3. EPL Service 3. EPL Service
skipping to change at page 13, line 5 skipping to change at page 13, line 5
5. Generic GMPLS Extensions 5. Generic GMPLS Extensions
This section presents extensions to GMPLS that, while motivated by This section presents extensions to GMPLS that, while motivated by
EPL and EVPL service, are generic in nature and may be useful to any EPL and EVPL service, are generic in nature and may be useful to any
switching technology controlled via GMPLS. switching technology controlled via GMPLS.
[AUTHORS' NOTE: The extensions presented in this section and may be [AUTHORS' NOTE: The extensions presented in this section and may be
split into one or more independent documents as this work split into one or more independent documents as this work
progresses.] progresses.]
5.1. Notify Message Format 5.1. Data Channel Switching
The Notify message format is extended based on the format defined in
[RFC4974] to allow for the use of the LSP_ATTRIBUTES object as
defined in this document. The inclusion of an LSP_ATTRIBUTES object
in Notify messages is optional. When present, the LSP_ATTRIBUTES
object SHOULD follow the SESSION_ATTRIBUTE object.
The format of the Notify Message is updated as follows:
<Notify message> ::= see [RFC4974]
<notify session> ::= <SESSION> [ <ADMIN_STATUS> ]
[ <POLICY_DATA> ...]
[ <LINK_CAPABILITY> ]
[ <SESSION_ATTRIBUTE> ]
[ <LSP_ATTRIBUTES> ]
[ <sender descriptor> | <flow descriptor> ]
<sender descriptor> ::= see [RFC3473]
<flow descriptor> ::= see [RFC3473]
5.2. Data Channel Switching
Current GMPLS switching types are defined in [RFC3945] and [RFC3471] Current GMPLS switching types are defined in [RFC3945] and [RFC3471]
and support switching at the packet (PSC), frame (L2SC), time-slot and support switching at the packet (PSC), frame (L2SC), time-slot
(TDM), frequency (LSC) and fiber (FSC) granularities. One type of (TDM), frequency (LSC) and fiber (FSC) granularities. One type of
switching that is not well represented in this current set switching switching that is not well represented in this current set switching
that takes all data received on an ingress port and switches it that takes all data received on an ingress port and switches it
through a network to an egress port. While there are similarities through a network to an egress port. While there are similarities
between this level of switching and the "opaque single wavelength" between this level of switching and the "opaque single wavelength"
case described in Section 3.5 of [RFC4202], such port-to-port case described in Section 3.5 of [RFC4202], such port-to-port
switching is not limited to the optical switching technology implied switching is not limited to the optical switching technology implied
skipping to change at page 14, line 11 skipping to change at page 13, line 35
digital channel are included. Examples include concatenated TDM and digital channel are included. Examples include concatenated TDM and
line encoded interfaces. Framed interfaces may also be included when line encoded interfaces. Framed interfaces may also be included when
they support switching on an interface granularity. they support switching on an interface granularity.
DCSC is represented in GMPLS, see [RFC3471] and [RFC4202], using the DCSC is represented in GMPLS, see [RFC3471] and [RFC4202], using the
value TBA (by IANA). value TBA (by IANA).
Port labels, as defined in [RFC3471], SHOULD be used for LSPs Port labels, as defined in [RFC3471], SHOULD be used for LSPs
signaled using the DCSC Switching Type. signaled using the DCSC Switching Type.
5.3. Generalized Channel_Set Label Related Formats 5.2. Generalized Channel_Set Label Related Formats
This section defines a new type of generalized label and updates This section defines a new type of generalized label and updates
related objects. This section updates the label related definitions related objects. This section updates the label related definitions
of [RFC3473]. The ability to communicate more than one label as part 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 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 one or more VLAN IDs, but the formats defined in this section are not
technology specific and may be useful for other switching technology specific and may be useful for other switching
technologies. technologies.
5.3.1. Generalized Channel_Set LABEL_REQUEST Object 5.2.1. Generalized Channel_Set LABEL_REQUEST Object
The Generalized Channel_Set LABEL_REQUEST object is used to indicate The Generalized Channel_Set LABEL_REQUEST object is used to indicate
that the Generalized Channel_Set LABEL Object is to be used with the that the Generalized Channel_Set LABEL Object is to be used with the
associated LSP. The format of the Generalized Channel_Set associated LSP. The format of the Generalized Channel_Set
LABEL_REQUEST object is the same as the Generalized LABEL_REQUEST LABEL_REQUEST object is the same as the Generalized LABEL_REQUEST
object and uses of C-Type of TBA. object and uses of C-Type of TBA.
5.3.2. Generalized Channel_Set LABEL Object 5.2.2. Generalized Channel_Set LABEL Object
The Generalized Channel_Set LABEL Object communicates one or more The Generalized Channel_Set LABEL Object communicates one or more
labels, all of which can be used equivalently in the data path labels, all of which can be used equivalently in the data path
associated with a single LSP. The format of the Generalized associated with a single LSP. The format of the Generalized
Channel_Set LABEL Object is based on the LABEL_SET object defined in 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 [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 set may be represented in a single object rather than the multiple
objects required by the [RFC3473] LABEL_SET object. The object MUST objects required by the [RFC3473] LABEL_SET object. The object MUST
be used on LSPs that use the Generalized Channel_Set LABEL_REQUEST be used on LSPs that use the Generalized Channel_Set LABEL_REQUEST
object. The object MUST be processed per [RFC3473]. Make-before- object. The object MUST be processed per [RFC3473]. Make-before-
break procedures, see [RFC3209], SHOULD be used when modifying the break procedures, see [RFC3209], SHOULD be used when modifying the
Channel_Set LABEL object. Channel_Set LABEL object.
The format of the Generalized Channel_Set LABEL object is: 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
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (16)| C-Type (TBA) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel_Set Sub-Object 1 | | Channel_Set Sub-Object 1 |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : : : :
: : : : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel_Set Sub-Object N | | Channel_Set Sub-Object N |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Channel_Set Sub-Object size is measured in bytes and MUST always 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: be a multiple of 4, and at least 4, and has the following format:
0 1 2 3 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 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 | | Action | Num Subchannels | Label Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel 1 | | Subchannel 1 |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 17, line 5 skipping to change at page 16, line 32
The Padding field MUST be included when the number of bits The Padding field MUST be included when the number of bits
represented in all the Subchannel fields included in a represented in all the Subchannel fields included in a
Generalized Channel_Set Sub-Object result in the Sub-Object not Generalized Channel_Set Sub-Object result in the Sub-Object not
being 32 bit aligned. When present, the Padding field MUST being 32 bit aligned. When present, the Padding field MUST
have a length that results in the Sub-Object being 32 bit have a length that results in the Sub-Object being 32 bit
aligned. When present, the Padding field MUST be set to a zero aligned. When present, the Padding field MUST be set to a zero
(0) value on transmission and MUST be ignored on receipt. (0) value on transmission and MUST be ignored on receipt.
These bits SHOULD be passed through unmodified by transit These bits SHOULD be passed through unmodified by transit
nodes. nodes.
5.3.3. Other Label related Objects 5.2.3. Other Label related Objects
The previous section introduces a new LABEL object. As such the The previous section introduces a new LABEL object. As such the
formats of the other label related objects are also impacted. formats of the other label related objects are also impacted.
Processing of these objects is not modified and remain per their Processing of these objects is not modified and remain per their
respective specifications. The other label related objects are respective specifications. The other label related objects are
defined in [RFC3473] and include: defined in [RFC3473] and include:
- SUGGESTED_LABEL object - SUGGESTED_LABEL object
- LABEL_SET object - LABEL_SET object
- ACCEPTABLE_LABEL_SET object - ACCEPTABLE_LABEL_SET object
- UPSTREAM_LABEL object - UPSTREAM_LABEL object
- RECOVERY_LABEL object - RECOVERY_LABEL object
6. IANA Considerations 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 6.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 "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:
Allowed on Allowed on Type Name Reference
Type Name LSP_ATTRIBUTES LSP_REQUIRED_ATTRIBUTES Reference ---- ----------- ---------
---- ----------- -------------- ----------------------- --------- 2* Endpoint ID [This document]
2* Endpoint ID Yes Yes [This document]
(*) Suggested value. (*) Suggested value.
6.2. Line LSP Encoding 6.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:
skipping to change at page 19, line 18 skipping to change at page 19, line 9
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 8. References
8.1. Normative References 8.1. Normative References
[MEF-TRAFFIC] Papadimitriou, D., "MEF Ethernet Traffic [ETH-TRAFFIC] Papadimitriou, D., "Ethernet Traffic Parameters,"
Parameters," draft-ietf-ccamp-ethernet-traffic-parameters-05.txt,
draft-ietf-ccamp-ethernet-traffic-parameters-03.txt, Work in progress, July 12, 2008.
Work in progress, November 2007.
[GMPLS-MRN] Papadimitriou, D. et al, "Generalized Multi-Protocol
Label Switching (GMPLS) Protocol Extensions for
Multi-Layer and Multi-Region Networks (MLN/MRN)",
draft-ietf-ccamp-gmpls-mln-extensions-02.txt,
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.,
Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions
to RSVP for LSP Tunnels", RFC 3209, December 2001. to RSVP for LSP Tunnels", RFC 3209, December 2001.
[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",
skipping to change at page 20, line 5 skipping to change at page 20, line 5
Switching (GMPLS) Architecture", RFC 3945, October Switching (GMPLS) Architecture", RFC 3945, October
2004. 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 [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
Extensions in Support of Generalized Multi-Protocol Extensions in Support of Generalized Multi-Protocol
Label Switching (GMPLS)", RFC 4202, October 2005. Label Switching (GMPLS)", RFC 4202, October 2005.
[RFC4420] Farrel, A., et al. "Encoding of Attributes for [4420BIS] Farrel, A., et al. "Encoding of Attributes for
Multiprotocol Label Switching (MPLS) Label Switched Path Multiprotocol Label Switching (MPLS) Label Switched
(LSP) Establishment Using Resource ReserVation Path (LSP) Establishment Using Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE)", RFC 4420, Protocol-Traffic Engineering (RSVP-TE)",
February 2006. draft-ietf-ccamp-rfc4420bis-03.txt,
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 8.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.
skipping to change at line 975 skipping to change at line 954
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 Apr 14 18:11:06 EDT 2008 Generated on: Mon Jul 14 12:19:42 EDT 2008
 End of changes. 37 change blocks. 
89 lines changed or deleted 68 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/