draft-ietf-ccamp-gmpls-ether-svcs-04.txt | rfc6004.txt | |||
---|---|---|---|---|
Internet Draft Lou Berger (LabN) | ||||
Category: Standards Track Don Fedyk (Alcatel-Lucent) | ||||
Expiration Date: April 14, 2010 | ||||
October 14, 2009 | Internet Engineering Task Force (IETF) L. Berger | |||
Request for Comments: 6004 LabN | ||||
Category: Standards Track D. Fedyk | ||||
ISSN: 2070-1721 Alcatel-Lucent | ||||
October 2010 | ||||
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-04.txt | Abstract | |||
Status of this Memo | ||||
This Internet-Draft is submitted to IETF in full conformance with the | ||||
provisions of BCP 78 and BCP 79. | ||||
By submitting this Internet-Draft, each author represents that any | ||||
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 | ||||
aware will be disclosed, in accordance with BCP 78 and BCP 79. | ||||
Internet-Drafts are working documents of the Internet Engineering | This document describes a method for controlling two specific types | |||
Task Force (IETF), its areas, and its working groups. Note that | of Ethernet switching via Generalized Multi-Protocol Label Switching | |||
other groups may also distribute working documents as Internet- | (GMPLS). This document supports the types of switching corresponding | |||
Drafts. | to the Ethernet services that have been defined in the context of the | |||
Metro Ethernet Forum (MEF) and International Telecommunication Union | ||||
(ITU) G.8011. Specifically, switching in support of Ethernet private | ||||
line and Ethernet virtual private line services are covered. Support | ||||
for MEF- and ITU-defined parameters is also covered. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | Status of This Memo | |||
and may be updated, replaced, or obsoleted by other documents at any | ||||
time. It is inappropriate to use Internet-Drafts as reference | ||||
material or to cite them other than as "work in progress." | ||||
The list of current Internet-Drafts can be accessed at | This is an Internet Standards Track document. | |||
http://www.ietf.org/1id-abstracts.html | ||||
The list of Internet-Draft Shadow Directories can be accessed at | This document is a product of the Internet Engineering Task Force | |||
http://www.ietf.org/shadow.html | (IETF). It represents the consensus of the IETF community. It has | |||
received public review and has been approved for publication by the | ||||
Internet Engineering Steering Group (IESG). Further information on | ||||
Internet Standards is available in Section 2 of RFC 5741. | ||||
This Internet-Draft will expire on April 14, 2010. | Information about the current status of this document, any errata, | |||
and how to provide feedback on it may be obtained at | ||||
http://www.rfc-editor.org/info/rfc6004. | ||||
Copyright and License Notice | Copyright Notice | |||
Copyright (c) 2009 IETF Trust and the persons identified as the | Copyright (c) 2010 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents in effect on the date of | Provisions Relating to IETF Documents | |||
publication of this document (http://trustee.ietf.org/license-info). | (http://trustee.ietf.org/license-info) in effect on the date of | |||
Please review these documents carefully, as they describe your rights | publication of this document. Please review these documents | |||
and restrictions with respect to this document. | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | ||||
Abstract | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | ||||
This document describes a method for controlling two specific types | described in the Simplified BSD License. | |||
of Ethernet switching via Generalized Multi-Protocol Label Switching | ||||
(GMPLS). This document supports the types of switching corresponding | ||||
to the Ethernet services that have been defined in the context of the | ||||
Metro Ethernet Forum (MEF) and International Telecommunication Union | ||||
(ITU) G.8011. Specifically, switching in support of Ethernet private | ||||
line and Ethernet virtual private line services are covered. Support | ||||
for MEF and ITU defined parameters is also covered. | ||||
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 ..........................4 | |||
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 .....................................5 | |||
2.2 Connection Identification .............................. 6 | 2.1.1.1. Procedures .................................6 | |||
2.2.1 Procedures ............................................. 7 | 2.2. Connection Identification ..................................6 | |||
2.3 Traffic Parameters ..................................... 7 | 2.2.1. Procedures ..........................................6 | |||
2.3.1 L2 Control Protocol TLV ................................ 7 | 2.3. Traffic Parameters .........................................7 | |||
2.4 Bundling and VLAN Identification ....................... 9 | 2.3.1. L2 Control Protocol TLV .............................7 | |||
3 EPL Service ............................................ 9 | 2.4. Bundling and VLAN Identification ...........................9 | |||
3.1 EPL Service Parameters ................................. 9 | 3. EPL Service .....................................................9 | |||
4 EVPL Service ........................................... 10 | 3.1. EPL Service Parameters .....................................9 | |||
4.1 EVPL Generalized Label Format .......................... 11 | 4. EVPL Service ...................................................10 | |||
4.2 Egress VLAN ID Control and VLAN ID preservation ........ 11 | 4.1. EVPL Generalized Label Format .............................10 | |||
4.3 Single Call - Single LSP ............................... 12 | 4.2. Egress VLAN ID Control and VLAN ID Preservation ...........11 | |||
4.4 Single Call - Multiple LSPs ............................ 12 | 4.3. Single Call - Single LSP ..................................11 | |||
5 IANA Considerations .................................... 12 | 4.4. Single Call - Multiple LSPs ...............................11 | |||
5.1 Endpoint ID Attributes TLV ............................. 12 | 5. IANA Considerations ............................................12 | |||
5.2 Line LSP Encoding ...................................... 13 | 5.1. Endpoint ID Attributes TLV ................................12 | |||
5.3 Ethernet Virtual Private Line (EVPL) Switching Type .... 13 | 5.2. Line LSP Encoding .........................................12 | |||
6 Security Considerations ................................ 13 | 5.3. Ethernet Virtual Private Line (EVPL) Switching Type .......12 | |||
7 References ............................................. 14 | 6. Security Considerations ........................................13 | |||
7.1 Normative References ................................... 14 | 7. References .....................................................13 | |||
7.2 Informative References ................................. 15 | 7.1. Normative References ......................................13 | |||
8 Acknowledgments ........................................ 15 | 7.2. Informative References ....................................14 | |||
9 Author's Addresses ..................................... 16 | Acknowledgments ...................................................14 | |||
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 | |||
service types. [MEF10.1] defines service parameters and [MEF11] | service types. [MEF10.1] defines service parameters and [MEF11] | |||
provides UNI requirements and framework. | provides UNI requirements and framework. | |||
[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 [RFC6005] 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] and the generic extensions defined in | defined in [RFC6003] and the generic extensions defined in [RFC6002]. | |||
[GMPLS-EXT]. | ||||
1.1. Overview | 1.1. Overview | |||
This document uses a common approach to supporting the switching | This document uses a common approach to supporting the switching | |||
corresponding to the Ethernet services defined in [MEF6], [G.8011.1] | corresponding to the Ethernet services defined in [MEF6], [G.8011.1], | |||
and [G.8011.2]. The approach builds on standard GMPLS mechanisms to | and [G.8011.2]. The approach builds on standard GMPLS mechanisms to | |||
deliver the required control capabilities. This document reuses the | deliver the required control capabilities. This document reuses the | |||
GMPLS mechanisms specified in [RFC3473] and [RFC4974]. The document | GMPLS mechanisms specified in [RFC3473] and [RFC4974]. The document | |||
uses the extensions defined in [GMPLS-EXT]. | uses the extensions defined in [RFC6002]. | |||
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 Traffic Engineering Label | |||
(LSPs), see [RFC3473], and unidirectional point-to-multipoint TE | Switched Paths (TE LSPs), see [RFC3473], and unidirectional point-to- | |||
LSPs, see [RFC4875]. | multipoint TE LSPs, see [RFC4875]. | |||
Support for P2P and MP2MP services is defined by [G.8011] and | Support for P2P and MP2MP services is defined by [G.8011] and | |||
required by [MEF11]. Note that while [MEF11] and [G.8011] discuss | required by [MEF11]. Note that while [MEF11] and [G.8011] discuss | |||
MP2MP, [G.8011.1] and [G.8011.2] only define support for P2P. There | MP2MP, [G.8011.1] and [G.8011.2] only define support for P2P. There | |||
is a clear correspondence between E-Line/P2P service and GMPLS P2P TE | is a clear correspondence between E-Line/P2P service and GMPLS P2P TE | |||
LSPs, and support for such LSPs is included in the scope of this | LSPs, and support for such LSPs is included in the scope of this | |||
document. There is no such clear correspondence between E-LAN/MP2MP | document. There is no such clear correspondence between E-LAN/MP2MP | |||
service and GMPLS TE LSPs. Although, it is possible to emulate this | service and GMPLS TE LSPs. Although, it is possible to emulate this | |||
service using multiple P2P or P2MP TE LSPs, the definition of support | 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 | for MP2MP service is left for future study and is not addressed in | |||
this document. | this document. | |||
[MEF11] defines multiple types of control for UNI Ethernet services. | [MEF11] defines multiple types of control for UNI Ethernet services. | |||
In MEF UNI Type 1, services are configured manually. In MEF UNI Type | In MEF UNI Type 1, services are configured manually. In MEF UNI Type | |||
2, services may be configured manually or via a link management | 2, services may be configured manually or via a link management | |||
interface. In MEF UNI Type 3, services may be established and | interface. In MEF UNI Type 3, services may be established and | |||
managed via a signaling interface. From the MEF perspective, this | managed via a signaling interface. From the MEF perspective, this | |||
document along with [GMPLS-MEF-UNI] is aimed at the network control | document, along with [RFC6005], is aimed at the network control | |||
needed to support the MEF UNI Type 3 mode of operation. | needed to support the MEF UNI Type 3 mode of operation. | |||
[G.8011.1], [G.8011.2] and [MEF11] together with [MEF10.1] define a | [G.8011.1], [G.8011.2], and [MEF11], together with [MEF10.1], define | |||
set of service attributes that are associated with each Ethernet | a set of service attributes that are associated with each Ethernet | |||
connection. Some of these attributes are based on the provisioning | connection. Some of these attributes are based on the provisioning | |||
of the local physical connection and are not modifiable or selectable | of the local physical connection and are not modifiable or selectable | |||
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 | |||
approach taken in this document to communicate these attributes is to | taken in this document to communicate these attributes is to exclude | |||
exclude the static class of attributes from signaling. This class of | 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 is communicated via signaling and will be | other class of attributes is 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 [ETH-TRAFFIC]) | - Traffic parameters (see [RFC6003]) | |||
- 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 the signaling of | Section 2 of this document. Procedures related to the signaling of | |||
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 the signaling of switching in support of EVPL | Procedures related to the signaling of switching in support of EVPL | |||
services are described in Section 4. | services are described in Section 4. | |||
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 | |||
signaled control of LSPs that provide Ethernet connections as defined | signaled control of LSPs that provide Ethernet connections as defined | |||
in [MEF11], [G.8011.1] and [G.8011.2]. | in [MEF11], [G.8011.1], and [G.8011.2]. | |||
Except as specifically modified in this document, the procedures | Except as specifically modified in this document, the procedures | |||
related to the processing of RSVP objects are not modified by this | related to the processing of RSVP objects are not modified by this | |||
document. The relevant procedures in existing documents, such as | document. The relevant procedures in existing documents, such as | |||
[RFC3473], MUST be followed in all cases not explicitly described in | [RFC3473], MUST be followed in all cases not explicitly described in | |||
this document. | this document. | |||
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 opposed to the GMPLS norm of being IP address based. | as opposed 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 a new CALL_ATTRIBUTES TLV defined in | Section 2.2 and [RFC4974], and a new CALL_ATTRIBUTES TLV defined in | |||
this document. The solution makes use of the [RFC4974] short call | this document. The solution makes use of the [RFC4974] short Call | |||
ID, and supports the Ethernet endpoint identifier similar to | ID, and supports the Ethernet endpoint identifier similar to how | |||
[RFC4974] supports the long call ID. That is, the SENDER_TEMPLATE | [RFC4974] supports the long Call ID. That is, the SENDER_TEMPLATE | |||
and SESSION objects carry IP addresses and a short call ID, and long | and SESSION objects carry IP addresses and a short Call ID, and long | |||
identifiers are carried in the CALL_ATTRIBUTES object. As with the | identifiers are carried in the CALL_ATTRIBUTES object. As with the | |||
long call ID, the Ethernet endpoint identifier is typically only | long Call ID, the Ethernet endpoint identifier is typically only | |||
relevant at the ingress and egress nodes. | relevant at the 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 | |||
CALL_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 CALL_ATTRIBUTES object in a Notify | requires the inclusion of the CALL_ATTRIBUTES object in a Notify | |||
message. | 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 | |||
[GMPLS-MRN]. The Endpoint ID TLV has the following format: | [RFC6001]. The Endpoint ID 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 (30) | Length (variable) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Endpoint ID | | | Endpoint ID | | |||
| ... | | | ... | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Type and Length fields are defined in [GMPLS-MRN]. Note that as | Type and Length fields are defined in [RFC6001]. Note that as | |||
defined in [GMPLS-MRN], the Length field is set to length of the | defined in [RFC6001], the Length field is set to length of the whole | |||
whole TLV including the Type, Length and Endpoint ID fields. | TLV including the Type, Length, and Endpoint ID fields. | |||
Endpoint ID | Endpoint ID | |||
The Endpoint ID field is a variable size field that carries an | The Endpoint ID field is a variable-size field that carries an | |||
endpoint identifier, see [MEF10.1] and [G.8011]. This field | endpoint identifier, see [MEF10.1] and [G.8011]. This field MUST | |||
MUST be null padded as defined in [GMPLS-MRN]. | be null padded as defined in [RFC6001]. | |||
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], a | When a Call is established or torn down per [RFC4974], a | |||
CALL_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]. | |||
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 used to | [RFC4974]. In particular, the Call-related mechanisms are used to | |||
support endpoint identification. In the context of Ethernet | support endpoint identification. In the context of Ethernet | |||
connections, a call is only established when one or more LSPs | connections, a Call is only established when one or more LSPs | |||
(connections in [RFC4974] terms) are needed. An LSP will always be | (connections in [RFC4974] terms) are needed. An LSP will always be | |||
established within the context of a call and, typically, only one LSP | established within the context of a Call and, typically, only one LSP | |||
will be used per call. See Section 4.4 for the case where more than | will be used per Call. See Section 4.4 for the case where more than | |||
one LSP may exist within a call. | one LSP may exist within a Call. | |||
2.2.1. Procedures | 2.2.1. Procedures | |||
Any node that supports Ethernet connections MUST be able to accept | Any node that supports Ethernet connections MUST be able to accept | |||
and process call setups per [RFC4974]. Ethernet connections | and process Call setups per [RFC4974]. Ethernet connections | |||
established according to this document MUST treat the Ethernet | established according to this document MUST treat the Ethernet | |||
(virtual) connection identifier as the long "Call identifier (ID)", | (virtual) connection identifier as the long "Call identifier (ID)", | |||
described in [RFC4974]. The short Call ID MUST be used as described | described in [RFC4974]. The short Call ID MUST be used as described | |||
in [RFC4974]. Use of the LINK_CAPABILITY object is OPTIONAL. Both | in [RFC4974]. Use of the LINK_CAPABILITY object is OPTIONAL. Both | |||
network-initiated and user-initiated Calls MUST be supported. | network-initiated and user-initiated Calls MUST be supported. | |||
When establishing an Ethernet connection the initiator MUST first | When establishing an Ethernet connection, the initiator MUST first | |||
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 [ETH-TRAFFIC]. These parameters are carried in | parameters defined in [RFC6003]. These parameters are carried in the | |||
the FLOWSPEC and TSPEC objects as discussed in [ETH-TRAFFIC]. The | FLOWSPEC and TSPEC objects as discussed in [RFC6003]. The service | |||
service attributes that are carried are: | attributes that are carried are: | |||
- Bandwidth Profile | - Bandwidth Profile | |||
- VLAN CoS Preservation | - VLAN Class of Service (CoS) Preservation | |||
- Layer Two (L2) Control Protocol Processing (see Section 2.3.1) | - Layer 2 Control Protocol (L2CP) 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 [ETH-TRAFFIC] in the FLOWSPEC and | the traffic parameters defined in [RFC6003] in the FLOWSPEC and TSPEC | |||
TSPEC objects. Additionally, the Switching Granularity field of the | objects. Additionally, the Switching Granularity field of the | |||
Ethernet SENDER_TSPEC object MUST be set to zero (0). | 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], [G.8011.1], and [G.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. [ETH-TRAFFIC] does not define support for these service | and egress. [RFC6003] 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 L2CP TLV to carry the L2CP-processing- | |||
L2 control protocol processing related service attributes. | 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=3 | Length=8 | | | Type=3 | Length=8 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| IL2CP | EL2CP | Reserved | | | IL2CP | EL2CP | Reserved | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
See [RFC6003] for a description of the Type and Length fields. | ||||
See [ETH-TRAFFIC] for a description of the Type and Length fields. | Per [RFC6003], the Type field MUST be set to three (3), and the | |||
Per [ETH-TRAFFIC], the Type field MUST be set to three (3), and | Length field MUST be set to eight (8) for the L2CP TLV. | |||
the 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 | |||
on a receiving interface. Valid usage is service specific, | a receiving interface. Valid usage is service specific, see | |||
see [MEF10.1], [8011.1] and [8011.2]. | [MEF10.1], [G.8011.1], and [G.8011.2]. | |||
Permitted values are: | Permitted values are: | |||
Value Description Reference | Value Description Reference | |||
----- ----------- --------- | ----- ----------- --------- | |||
0 Reserved | 0 Reserved | |||
1 Discard/Block [MEF10.1], [8011.1] and [8011.2] | 1 Discard/Block [MEF10.1], [G.8011.1], and [G.8011.2] | |||
2 Peer/Process [MEF10.1], [8011.1] and [8011.2] | 2 Peer/Process [MEF10.1], [G.8011.1], and [G.8011.2] | |||
3 Pass to EVC/Pass [MEF10.1], [8011.1] and [8011.2] | 3 Pass to EVC/Pass [MEF10.1], [G.8011.1], and [G.8011.2] | |||
4 Peer and Pass to EVC [MEF10.1] | 4 Peer and Pass to EVC [MEF10.1] | |||
Egress Layer 2 Control Processing (EL2CP): 4 bits | Egress Layer 2 Control Processing (EL2CP): 4 bits | |||
This field controls processing of Layer 2 Control Protocols on | This field controls processing of Layer 2 Control Protocols on a | |||
a transmitting interface. When MEF services are used a value | transmitting interface. When MEF services are used a value of 1 MUST | |||
of 1 MUST be used, other valid usage is service specific, see | be used, other valid usage is service specific, see [G.8011.1] and | |||
[8011.1] and [8011.2]. | [G.8011.2]. | |||
Permitted values are: | Permitted values are: | |||
Value Description Reference | Value Description Reference | |||
----- ----------- --------- | ----- ----------- --------- | |||
0 Reserved | 0 Reserved | |||
1 Based on IL2CP Value [MEF10.1] | 1 Based on IL2CP Value [MEF10.1] | |||
2 Generate [8011.1] and [8011.2] | 2 Generate [G.8011.1] and [G.8011.2] | |||
3 None [8011.1] and [8011.2] | 3 None [G.8011.1] and [G.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 | |||
and MUST be ignored on receipt. This field SHOULD be passed | MUST be ignored on receipt. This field SHOULD be passed unmodified | |||
unmodified by transit nodes. | 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 [ETH-TRAFFIC] traffic parameters carried | include the L2CP TLV in the [RFC6003] traffic parameters carried in | |||
in the FLOWSPEC and TSPEC objects. | 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 | |||
Both [MEF6] and [G.8011.1] define an Ethernet Private Line (EPL) | Both [MEF6] and [G.8011.1] define an Ethernet Private Line (EPL) | |||
service. In the words of [G.8011.1], EPL services carry "Ethernet | service. In the words of [G.8011.1], EPL services carry "Ethernet | |||
characteristic information over dedicated bandwidth, point-to-point | characteristic information over dedicated bandwidth, point-to-point | |||
connections, provided by SDH, ATM, MPLS, PDH, ETY or OTH server layer | connections, provided by SDH, ATM, MPLS, PDH, ETY or OTH server layer | |||
networks." [G.8011.1] defines two types of Ethernet Private Line | networks". [G.8011.1] defines two types of Ethernet Private Line | |||
(EPL) services. Both types present a service where all data | (EPL) services. Both types present a service where all data | |||
presented on a port is transported to the corresponding connect port. | presented on a port is transported to the corresponding connected | |||
The types differ in that EPL type 1 service operates at the MAC frame | port. The types differ in that EPL type 1 service operates at the | |||
layer, while EPL type 2 service operates at the line (e.g., 8B/10B) | MAC frame layer, while EPL type 2 service operates at the line (e.g., | |||
encoding layer. [MEF6] only defines one type of EPL service, and it | 8B/10B) encoding layer. [MEF6] only defines one type of EPL service, | |||
matches [G.8011.1] EPL type 1 service. Signaling for LSPs that | and it matches [G.8011.1] EPL type 1 service. Signaling for LSPs | |||
support both types of EPL services are detailed below. | that support both types of EPL services are detailed below. | |||
3.1. EPL Service Parameters | 3.1. EPL Service Parameters | |||
Signaling for the EPL service types only differ in the LSP Encoding | Signaling for the EPL service types only differ in the LSP Encoding | |||
Type used. The LSP Encoding Type used for each are: | Type used. The LSP Encoding Type used for each are: | |||
EPL Service LSP Encoding Type | EPL Service LSP Encoding Type (Value) Reference | |||
----------- ----------------- | ----------- ------------------------- --------- | |||
Type 1/MEF Ethernet (2) [RFC3471] | Type 1/MEF Ethernet (2) [RFC3471] | |||
Type 2 Line (e.g., 8B/10B) [This document] (TBA by IANA) | Type 2 Line (e.g., 8B/10B)(14) [RFC6004] | |||
The other LSP parameters specific to EPL Service are: | The other LSP parameters specific to EPL Service are: | |||
Parameter Value | Parameter Name (Value) Reference | |||
-------------- ----- | -------------- ----------------- ------------------ | |||
Switching Type DCSC [GMPLS-EXT] | Switching Type DCSC (125) [RFC6002] | |||
G-PID Ethernet (33) [RFC3471] | G-PID Ethernet PHY (33) [RFC3471][RFC4328] | |||
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 | |||
EVPL service is defined within the context of both [G.8011.2] and | EVPL service is defined within the context of both [G.8011.2] and | |||
[MEF6]. EVPL service allows for multiple Ethernet connections per | [MEF6]. EVPL service allows for multiple Ethernet connections per | |||
port, each of which supports a specific set of VLAN IDs. The service | port, each of which supports a specific set of VLAN IDs. The service | |||
attributes identify different forms of EVPL services, e.g., bundled | attributes identify different forms of EVPL services, e.g., bundled | |||
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 Name (Value) Reference | |||
-------------- ----- | -------------- ----------------- ------------------ | |||
Switching Type EVPL [This document] (TBA by IANA) | Switching Type EVPL (30) [RFC6004] | |||
LSP Encoding Type Ethernet (2) | LSP Encoding Type Ethernet (2) [RFC3471] | |||
G-PID Ethernet (33) | G-PID Ethernet PHY (33) [RFC3471][RFC4328] | |||
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 [GMPLS-EXT]. A notable implication of | Channel_Set Label Objects per [RFC6002]. 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 require the use of a service specific label, | Bundled EVPL services require the use of a service-specific label, | |||
called the EVPL Generalized Label. For consistency, Non-bundled EVPL | called the EVPL Generalized Label. For consistency, non-bundled EVPL | |||
services also use the same label. | services also use the same label. | |||
The format for the Generalized Label (Label Type value 2) used with | The format for the Generalized Label (Label Type value 2) used with | |||
EVPL services is: | EVPL services is: | |||
0 1 | 0 1 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Rsvd | VLAN ID | | | Rsvd | VLAN ID | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Reserved: 4 bits | Reserved: 4 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. | |||
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 | |||
When an EVPL service is not configured for both bundling and VLAN ID | When an EVPL service is not configured for both bundling and VLAN ID | |||
preservation, [MEF6] allows VLAN ID mapping. In particular, the | preservation, [MEF6] allows VLAN ID mapping. In particular, the | |||
single VLAN ID used at the incoming interface of the ingress may be | 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 | mapped to a different VLAN ID at the outgoing interface at the egress | |||
UNI. Such mapping MUST be requested and signaled based on the | UNI. Such mapping MUST be requested and signaled based on the | |||
explicit label control mechanism defined in [RFC3473] and clarified | explicit label control mechanism defined in [RFC3473] and clarified | |||
in [RFC4003]. | 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, | |||
[GMPLS-EXT], make-before-break procedures SHOULD be used to modify | [RFC6002], make-before-break procedures SHOULD be used to modify the | |||
the Channel_Set LABEL object. | 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 in which 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 | |||
EVPL connection MUST be signaled with the same LSP objects with the | 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 re-signal all | |||
LSPs associated with the call via make-before-break procedures. | LSPs associated with the Call via make-before-break procedures. | |||
5. IANA Considerations | 5. IANA Considerations | |||
IANA is requested to administer assignment of new values for | IANA has assigned new values for namespaces defined in this document | |||
namespaces defined in this document and summarized in this section. | and summarized in this section. The registries are available from | |||
http://www.iana.org. | ||||
5.1. Endpoint ID Attributes TLV | 5.1. Endpoint ID Attributes TLV | |||
Upon approval of this document, IANA will make the assignment in the | IANA has made the following assignment in the "Call Attributes TLV" | |||
"CALL_ATTRIBUTES TLV Space" section of the "RSVP TE Parameters" | section of the "RSVP Parameters" registry. | |||
registry located at http://www.iana.org/assignments/rsvp-te- | ||||
parameters: | ||||
Type Name Reference | Type Name Reference | |||
---- ----------- --------- | ---- ----------- --------- | |||
2* Endpoint ID [This document] | 2 Endpoint ID [RFC6004] | |||
(*) Suggested value. | ||||
5.2. Line LSP Encoding | 5.2. Line LSP Encoding | |||
Upon approval of this document, IANA will make the assignment in the | IANA has made the following assignment in the "LSP Encoding Types" | |||
"LSP Encoding Types" section of the "GMPLS Signaling Parameters" | section of the "GMPLS Signaling Parameters" registry. | |||
registry located at http://www.iana.org/assignments/gmpls-sig- | ||||
parameters: | ||||
Value Type Reference | Value Type Reference | |||
----- --------------------------- --------- | ----- --------------------------- --------- | |||
14* Line (e.g., 8B/10B) [This document] | 14 Line (e.g., 8B/10B) [RFC6004] | |||
(*) Suggested value. | ||||
5.3. Ethernet Virtual Private Line (EVPL) Switching Type | 5.3. Ethernet Virtual Private Line (EVPL) Switching Type | |||
Upon approval of this document, IANA will make the assignment in the | IANA has made the following assignment in the "Switching Types" | |||
"Switching Types" section of the "GMPLS Signaling Parameters" | section of the "GMPLS Signaling Parameters" registry. | |||
registry located at http://www.iana.org/assignments/gmpls-sig- | ||||
parameters: | ||||
Value Type Reference | Value Type Reference | |||
----- --------------------------- --------- | ----- ------------------------------------ --------- | |||
30* Ethernet Virtual Private Line (EVPL) [This document] | 30 Ethernet Virtual Private Line (EVPL) [RFC6004] | |||
(*) Suggested value. | ||||
It should be noted that the assigned value should be reflected in | The assigned value has been reflected in IANAGmplsSwitchingTypeTC of | |||
IANAGmplsSwitchingTypeTC at | the IANA-GMPLS-TC-MIB available from http://www.iana.org. | |||
http://www.iana.org/assignments/ianagmplstc-mib. | ||||
6. Security Considerations | 6. 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 Label Switching Routers | |||
in the control plane. As such, this document introduces no additional | (LSRs) that are adjacent in the control plane. As such, this | |||
security considerations. See [RFC3473] for relevant security | document introduces no additional security considerations to those | |||
considerations. | discussed in [RFC3473]. | |||
7. References | 7. References | |||
7.1. Normative References | 7.1. Normative References | |||
[ETH-TRAFFIC] Papadimitriou, D., "Ethernet Traffic Parameters," | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
draft-ietf-ccamp-ethernet-traffic-parameters, | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
Work in progress. | ||||
[GMPLS-EXT] Berger, L., Fedyk, D., "Generalized MPLS (GMPLS) Data | [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., | |||
Channel Switching Capable (DCSC) and Channel Set | and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP | |||
Label Extensions", | Tunnels", RFC 3209, December 2001. | |||
draft-ietf-ccamp-gmpls-dcsc-channel-ext, Work in | ||||
Progres. | ||||
[GMPLS-MRN] Papadimitriou, D. et al, "Generalized Multi-Protocol | [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label | |||
Label Switching (GMPLS) Protocol Extensions for | Switching (GMPLS) Signaling Functional Description", RFC | |||
Multi-Layer and Multi-Region Networks (MLN/MRN)", | 3471, January 2003. | |||
draft-ietf-ccamp-gmpls-mln-extensions, | ||||
Work in progress. | ||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label | |||
Requirement Levels," RFC 2119. | Switching (GMPLS) Signaling Resource ReserVation Protocol- | |||
Traffic Engineering (RSVP-TE) Extensions", RFC 3473, | ||||
January 2003. | ||||
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., | [RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress | |||
Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions | Control", RFC 4003, February 2005. | |||
to RSVP for LSP Tunnels", RFC 3209, December 2001. | ||||
[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label | [RFC4974] Papadimitriou, D. and A. Farrel, "Generalized MPLS (GMPLS) | |||
Switching (GMPLS) Signaling Functional Description", | RSVP-TE Signaling Extensions in Support of Calls", RFC | |||
RFC 3471, January 2003. | 4974, August 2007. | |||
[RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label | [RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard, | |||
Switching (GMPLS) Signaling - Resource ReserVation | D. and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol | |||
Protocol-Traffic Engineering (RSVP-TE) Extensions", | Extensions for Multi-Layer and Multi-Region Networks | |||
RFC 3473, January 2003. | (MLN/MRN)", RFC 6001, October 2010. | |||
[RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress | [RFC6002] Berger, L. and D. Fedyk, "Generalized MPLS (GMPLS) Data | |||
Control", RFC 4003, February 2005. | Channel Switching Capable (DCSC) and Channel Set Label | |||
Extensions", RFC 6002, October 2010. | ||||
[RFC4974] Papadimitriou, D., Farrel, A. "Generalized MPLS | [RFC6003] Papadimitriou, D., "Ethernet Traffic Parameters," RFC | |||
(GMPLS) RSVP-TE Signaling Extensions in support of Calls", | 6003, October 2010. | |||
RFC 4974, August 2007. | ||||
7.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 | |||
Ethernet services framework", August 2004. | 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 | |||
line service", August 2004. | 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 | |||
private line service", September 2005. | service", September 2005. | |||
[GMPLS-MEF-UNI] Berger, L., Fedyk, D., "Generalized MPLS (GMPLS) | [MEF6] The Metro Ethernet Forum, "Ethernet Services Definitions - | |||
Support For Metro Ethernet Forum and G.8011 | Phase I", MEF 6, June 2004. | |||
User-Network Interface (UNI)", | ||||
draft-ietf-ccamp-gmpls-mef-uni, Work in Progress. | ||||
[MEF6] The Metro Ethernet Forum, "Ethernet Services | [MEF10.1] The Metro Ethernet Forum, "Ethernet Services Attributes | |||
Definitions - Phase I", MEF 6, June 2004 | Phase 2", MEF 10.1, November 2006. | |||
[MEF10.1] The Metro Ethernet Forum, "Ethernet Services | [MEF11] The Metro Ethernet Forum , "User Network Interface (UNI) | |||
Attributes Phase 2", MEF 10.1, November 2006. | Requirements and Framework", MEF 11, November 2004. | |||
[MEF11] The Metro Ethernet Forum , "User Network | [RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label | |||
Interface (UNI) Requirements and Framework", | Switching (GMPLS) Signaling Extensions for G.709 Optical | |||
MEF 11, November 2004. | Transport Networks Control", RFC 4328, January 2006. | |||
[RFC4875] Aggarwal, R., Papadimitriou, P., Yasukawa, S., | [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. | |||
Eds, "Extensions to Resource Reservation | Yasukawa, Ed., "Extensions to Resource Reservation | |||
Protocol - Traffic Engineering (RSVP-TE) for | Protocol - Traffic Engineering (RSVP-TE) for Point-to- | |||
Point-to-Multipoint TE Label Switched Paths | Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May | |||
(LSPs)", RFC 4875, May 2007. | 2007. | |||
8. Acknowledgments | [RFC6005] Berger, L. and D. Fedyk,"Generalized MPLS (GMPLS) Support | |||
for Metro Ethernet Forum and G.8011 User Network Interface | ||||
(UNI)", RFC 6005, October 2010. | ||||
Acknowledgments | ||||
Dimitri Papadimitriou provided substantial textual contributions to | Dimitri Papadimitriou provided substantial textual contributions to | |||
this document and coauthored earlier versions of this document. | this document and coauthored earlier versions of this document. | |||
The authors would like to thank Evelyne Roch, Stephen Shew, and Yoav | The authors would like to thank Evelyne Roch, Stephen Shew, and Yoav | |||
Cohen for their valuable comments. | Cohen for their valuable comments. | |||
9. Author's Addresses | Authors' 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 | |||
Don Fedyk | Don Fedyk | |||
Alcatel-Lucent | Alcatel-Lucent | |||
Groton, MA, 01450 | Groton, MA 01450 | |||
Phone: +1-978-467-5645 | Phone: +1-978-467-5645 | |||
Email: donald.fedyk@alcatel-lucent.com | EMail: donald.fedyk@alcatel-lucent.com | |||
Generated on: Wed Oct 14 14:47:45 EDT 2009 | ||||
End of changes. 134 change blocks. | ||||
325 lines changed or deleted | 300 lines changed or added | |||
This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |