draft-ietf-ccamp-gmpls-ether-svcs-02.txt | draft-ietf-ccamp-gmpls-ether-svcs-03.txt | |||
---|---|---|---|---|
Internet Draft Lou Berger (LabN) | Internet Draft Lou Berger (LabN) | |||
Category: Standards Track Don Fedyk (Nortel) | Category: Standards Track Don Fedyk (Nortel) | |||
Expiration Date: February 8, 2009 | Expiration Date: August 25, 2009 | |||
August 8, 2008 | February 25, 2009 | |||
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-02.txt | draft-ietf-ccamp-gmpls-ether-svcs-03.txt | |||
Status of this Memo | 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 | 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 BCP 78 and 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 | |||
other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
Drafts. | Drafts. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
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 February 8, 2009. | This Internet-Draft will expire on August 25, 2009. | |||
Copyright Notice | Copyright and License Notice | |||
Copyright (C) The IETF Trust (2008). | Copyright (c) 2009 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | ||||
This document is subject to BCP 78 and the IETF Trust's Legal | ||||
Provisions Relating to IETF Documents | ||||
(http://trustee.ietf.org/license-info) in effect on the date of | ||||
publication of this document. Please review these documents | ||||
carefully, as they describe your rights and restrictions with respect | ||||
to this document. | ||||
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 implied by | (GMPLS). This document supports the types of switching implied by | |||
the Ethernet services that have been defined in the context of the | the Ethernet services that have been defined in the context of the | |||
Metro Ethernet Forum (MEF) and International Telecommunication Union | Metro Ethernet Forum (MEF) and International Telecommunication Union | |||
(ITU) G.8011. Specifically, switching in support of Ethernet private | (ITU) G.8011. Specifically, switching in support of Ethernet private | |||
line service and Ethernet virtual private line service. Support for | line and Ethernet virtual private line services. Support for MEF and | |||
MEF and ITU defined parameters are also covered. Some of the | ITU defined parameters are also covered. | |||
extensions defined in this document are generic in nature and not | ||||
specific to Ethernet. | ||||
Table of Contents | Table of Contents | |||
1 Introduction .............................................. 3 | 1 Introduction ........................................... 3 | |||
1.1 Overview .................................................. 3 | 1.1 Overview ............................................... 3 | |||
1.2 Conventions used in this document ......................... 5 | 1.2 Conventions used in this document ...................... 5 | |||
2 Common Signaling Support .................................. 5 | 2 Common Signaling Support ............................... 5 | |||
2.1 Ethernet Endpoint Identification .......................... 5 | 2.1 Ethernet Endpoint Identification ....................... 5 | |||
2.1.1 Endpoint ID TLV ........................................... 6 | 2.1.1 Endpoint ID TLV ........................................ 6 | |||
2.2 Connection Identification ................................. 7 | 2.2 Connection Identification .............................. 6 | |||
2.2.1 Procedures ................................................ 7 | 2.2.1 Procedures ............................................. 7 | |||
2.3 Traffic Parameters ........................................ 7 | 2.3 Traffic Parameters ..................................... 7 | |||
2.3.1 L2 Control Protocol TLV ................................... 8 | 2.3.1 L2 Control Protocol TLV ................................ 7 | |||
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 ................................. 9 | |||
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 IANA Considerations ....................................... 12 | 5 IANA Considerations .................................... 12 | |||
5.1 Endpoint ID Attributes TLV ................................ 13 | 5.1 Endpoint ID Attributes TLV ............................. 12 | |||
5.2 Line LSP Encoding ......................................... 13 | 5.2 Line LSP Encoding ...................................... 13 | |||
6 Security Considerations ................................... 13 | 5.3 Ethernet Virtual Private Line (EVPL) Switching Type .... 13 | |||
7 References ................................................ 13 | 6 Security Considerations ................................ 13 | |||
7.1 Normative References ...................................... 13 | 7 References ............................................. 14 | |||
7.2 Informative References .................................... 14 | 7.1 Normative References ................................... 14 | |||
8 Acknowledgments ........................................... 15 | 7.2 Informative References ................................. 15 | |||
9 Author's Addresses ........................................ 15 | 8 Acknowledgments ........................................ 15 | |||
10 Full Copyright Statement .................................. 16 | 9 Author's Addresses ..................................... 16 | |||
11 Intellectual Property ..................................... 16 | ||||
1. Introduction | 1. Introduction | |||
[MEF6] and [G.8011] provide parallel frameworks for defining network- | [MEF6] and [G.8011] provide parallel frameworks for defining network- | |||
oriented characteristics of Ethernet services in transport networks. | oriented characteristics of Ethernet services in transport networks. | |||
The framework discusses general Ethernet connection characteristics, | The framework discusses general Ethernet connection characteristics, | |||
Ethernet User-Network Interfaces (UNIs) and Ethernet Network-Network | Ethernet User-Network Interfaces (UNIs) and Ethernet Network-Network | |||
Interfaces (NNIs). Within this framework, [G.8011.1] defines the | Interfaces (NNIs). Within this framework, [G.8011.1] defines the | |||
Ethernet Private Line (EPL) service and [G.8011.2] defines the | Ethernet Private Line (EPL) service and [G.8011.2] defines the | |||
Ethernet Virtual Private Line (EVPL) service. [MEF6] covers both | Ethernet Virtual Private Line (EVPL) service. [MEF6] covers both | |||
skipping to change at page 3, line 50 | skipping to change at page 3, line 50 | |||
[MEF6] and [G.8011]: point-to-point (P2P) and multipoint-to- | [MEF6] and [G.8011]: point-to-point (P2P) and multipoint-to- | |||
multipoint (MP2MP). [MEF6] uses the term Ethernet Line (E-line) to | multipoint (MP2MP). [MEF6] uses the term Ethernet Line (E-line) to | |||
refer to point-to-point virtual connections, and Ethernet LAN (E-LAN) | refer to point-to-point virtual connections, and Ethernet LAN (E-LAN) | |||
to refer to multipoint-to-multipoint virtual connections. [G.8011] | to refer to multipoint-to-multipoint virtual connections. [G.8011] | |||
also identifies point-to-multipoint (P2MP) as an area for "further | also identifies point-to-multipoint (P2MP) as an area for "further | |||
study." Within the context of GMPLS, support is defined for point- | study." Within the context of GMPLS, support is defined for point- | |||
to-point unidirectional and bidirectional TE Label Switched Paths | to-point unidirectional and bidirectional TE Label Switched Paths | |||
(LSPs), see [RFC3473], and unidirectional point-to-multipoint TE | (LSPs), see [RFC3473], and unidirectional point-to-multipoint TE | |||
LSPs, see [RFC4875]. | LSPs, see [RFC4875]. | |||
Support for P2P and MP2MP service is required by [G.8011] and | Support for P2P and MP2MP services is required by [G.8011] and | |||
[MEF11]. Note that while [MEF11] requires MP2MP, [G.8011.1] and | [MEF11]. Note that while [MEF11] requires MP2MP, [G.8011.1] and | |||
[G.8011.2] only require P2P. There is a clear correspondence between | [G.8011.2] only require P2P. There is a clear correspondence between | |||
E-Line/P2P service and GMPLS P2P TE LSPs, and support for such LSPs | E-Line/P2P service and GMPLS P2P TE LSPs, and support for such LSPs | |||
are included in the scope of this document. There is no such clear | are included in the scope of this document. There is no such clear | |||
correspondence between E-LAN/MP2MP service and GMPLS TE LSPs. | correspondence between E-LAN/MP2MP service and GMPLS TE LSPs. | |||
Although it is possible to emulate the service using multiple P2P or | Although it is possible to emulate the service using multiple P2P or | |||
P2MP TE LSPs. The definition of support for MP2MP service is left | P2MP TE LSPs. The definition of support for MP2MP service is left | |||
for future study and is not addressed in this document. | for future study and is not addressed in this document. | |||
[MEF11] defines multiple types of control for UNI Ethernet services. | [MEF11] defines multiple types of control for UNI Ethernet services. | |||
skipping to change at page 5, line 18 | skipping to change at page 5, line 18 | |||
"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 is 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 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 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 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 CALL_ATTRIBUTES object. As with the long call ID, | |||
Ethernet endpoint identifier is typically only relevant at the | 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 | |||
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 | |||
skipping to change at page 6, line 40 | skipping to change at page 6, line 40 | |||
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]. | |||
A CALL_ATTRIBUTES object containing an Endpoint ID TLV MAY be | ||||
included in the signaling messages of an LSP (connection) associated | ||||
with an established call. Such objects are processed according to | ||||
[4420BIS]. | ||||
Transit nodes supporting this document MUST propagate the Endpoint ID | ||||
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 is only established when one or more LSPs | |||
[RFC4974] terms) are present. An LSP will always be established | (connections in [RFC4974] terms) are needed. An LSP will always be | |||
within the context of a call and, typically, only one LSP will be | established within the context of a call and, typically, only one LSP | |||
used per call. See Section 4.4 for the case where more than one LSP | will be used per call. See Section 4.4 for the case where more than | |||
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. | |||
skipping to change at page 8, line 25 | skipping to change at page 8, line 16 | |||
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 [ETH-TRAFFIC] for a description of the Type and Length fields. | See [ETH-TRAFFIC] for a description of the Type and Length fields. | |||
Per [ETH-TRAFFIC], the Type field MUST be set to two (2), 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 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 34 | skipping to change at page 9, line 23 | |||
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) | |||
services. 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 connect port. | |||
The types differ in that EPL type 1 service operates at the MAC frame | The types differ in that EPL type 1 service operates at the MAC frame | |||
layer, while EPL type 2 service operates at the line (e.g., 8B/10B) | layer, while EPL type 2 service operates at the line (e.g., 8B/10B) | |||
encoding layer. [MEF6] only defines one type of EPL service, and it | encoding layer. [MEF6] only defines one type of EPL service, and it | |||
matches [G.8011.1] EPL type 1 service. Signaling for LSPs that | matches [G.8011.1] EPL type 1 service. Signaling for LSPs that | |||
support both types of EPL services are detailed below. | 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 | |||
----------- ----------------- | ----------- ----------------- | |||
Type 1/MEF Ethernet (2) [RFC3471] | Type 1/MEF Ethernet (2) [RFC3471] | |||
Type 2 Line (e.g., 8B/10B) (TBA by IANA) | Type 2 Line (e.g., 8B/10B) [This document] (TBA by IANA) | |||
The other LSP parameters specific to EPL Service are: | The other LSP parameters specific to EPL Service are: | |||
Parameter Value | Parameter Value | |||
-------------- ----- | -------------- ----- | |||
Switching Type DCSC [GMPLS-EXT] | Switching Type DCSC [GMPLS-EXT] | |||
G-PID Ethernet (33) [RFC3471] | G-PID Ethernet (33) [RFC3471] | |||
The parameters defined in this section MUST be used when establishing | The parameters defined in this section MUST be used when establishing | |||
and controlling LSPs that provide EPL service type Ethernet | and controlling LSPs that provide EPL service type Ethernet | |||
switching. The procedures defined in Section 2 and the other | switching. The procedures defined in Section 2 and the other | |||
skipping to change at page 10, line 45 | skipping to change at page 10, line 34 | |||
or unbundled. Independent of the different forms, LSPs supporting | or unbundled. Independent of the different forms, LSPs supporting | |||
EVPL Ethernet type switching are signaled using the same mechanisms | EVPL Ethernet type switching are signaled using the same mechanisms | |||
to communicate the one or more VLAN IDs associated with a particular | to communicate the one or more VLAN IDs associated with a particular | |||
LSP (Ethernet connection). | LSP (Ethernet connection). | |||
The relevant [RFC3471] parameter values that MUST be used for EVPL | The relevant [RFC3471] parameter values that MUST be used for EVPL | |||
connections are: | connections are: | |||
Parameter Value | Parameter Value | |||
-------------- ----- | -------------- ----- | |||
Switching Type TBD [NOTE: under discussion] | Switching Type EVPL [This document] (TBA by IANA) | |||
LSP Encoding Type Ethernet (2) | LSP Encoding Type Ethernet (2) | |||
G-PID Ethernet (33) | G-PID Ethernet (33) | |||
As with EPL, the procedures defined in Section 2 and the other | As with EPL, the procedures defined in Section 2 and the other | |||
procedures defined in [RFC3473] for the establishment and management | procedures defined in [RFC3473] for the establishment and management | |||
of bidirectional LSPs MUST be followed when establishing and | of bidirectional LSPs MUST be followed when establishing and | |||
controlling LSPs that provide EVPL service type Ethernet switching. | controlling LSPs that provide EVPL service type Ethernet switching. | |||
LSPs that provide EVPL service type Ethernet switching MUST use the | LSPs that provide EVPL service type Ethernet switching MUST use the | |||
EVPL Generalized Label Format per Section 4.1, and the Generalized | EVPL Generalized Label Format per Section 4.1, and the Generalized | |||
Channel_Set Label Objects per [GMPLS-EXT]. A notable implication of | Channel_Set Label Objects per [GMPLS-EXT]. A notable implication of | |||
bundled EVPL services and carrying multiple VLAN IDs is that a Path | bundled EVPL services and carrying multiple VLAN IDs is that a Path | |||
message may grow to be larger than a single (fragmented or non- | message may grow to be larger than a single (fragmented or non- | |||
fragmented) IP packet. The basic approach to solving this is to | fragmented) IP packet. The basic approach to solving this is to | |||
allow for multiple LSPs which are associated with a single call, see | allow for multiple LSPs which are associated with a single call, see | |||
Section 2.2. The specifics of this approach are describe below in | Section 2.2. The specifics of this approach are describe below in | |||
Section 4.4. | Section 4.4. | |||
4.1. EVPL Generalized Label Format | 4.1. EVPL Generalized Label Format | |||
Bundled EVPL services requires the use of a service specific label, | Bundled EVPL services 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 | | |||
skipping to change at page 11, line 44 | skipping to change at page 11, line 33 | |||
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 | |||
Per [MEF6], the mapping of the single VLAN ID used at the incoming | When an EVPL service does not support both bundling and VLAN ID | |||
interface of the ingress to a different VLAN ID at the outgoing | preservation, [MEF6] allows VLAN ID mapping. In particular, the | |||
interface at the egress UNI is allowed for EVPL services that do not | single VLAN ID used at the incoming interface of the ingress may be | |||
support either bundling and VLAN ID preservation. Such a mapping | mapped to a different VLAN ID at the outgoing interface at the egress | |||
MUST be requested and signaled based on the explicit label control | UNI. Such mapping MUST be requested and signaled based on the | |||
mechanism defined in [RFC3473] and clarified in [RFC4003]. | explicit label control mechanism defined in [RFC3473] and clarified | |||
in [RFC4003]. | ||||
When the explicit label control mechanism is not used, VLAN IDs MUST | When the explicit label control mechanism is not used, VLAN IDs MUST | |||
be preserved, i.e., not modified, across an LSP. | be preserved, i.e., not modified, across an LSP. | |||
4.3. Single Call - Single LSP | 4.3. Single Call - Single LSP | |||
For simplicity in management, a single LSP SHOULD be used for each | For simplicity in management, a single LSP SHOULD be used for each | |||
EVPL type LSP whose Path and Resv messages fit within a single | EVPL type LSP whose Path and Resv messages fit within a single | |||
unfragmented IP packet. This allows the reuse of all standard LSP | unfragmented IP packet. This allows the reuse of all standard LSP | |||
modification procedures. Of particular note is the modification of | modification procedures. Of particular note is the modification of | |||
skipping to change at page 13, line 31 | skipping to change at page 13, line 24 | |||
the "LSP Encoding Types" section of the "GMPLS Signaling Parameters" | the "LSP Encoding Types" section of the "GMPLS Signaling Parameters" | |||
registry located at http://www.iana.org/assignments/gmpls-sig- | registry located at http://www.iana.org/assignments/gmpls-sig- | |||
parameters: | parameters: | |||
Value Type Reference | Value Type Reference | |||
----- --------------------------- --------- | ----- --------------------------- --------- | |||
14* Line (e.g., 8B/10B) [This document] | 14* Line (e.g., 8B/10B) [This document] | |||
(*) Suggested value. | (*) Suggested value. | |||
5.3. Ethernet Virtual Private Line (EVPL) Switching Type | ||||
Upon approval of this document, the IANA will make the assignment in | ||||
the "Switching Types" section of the "GMPLS Signaling Parameters" | ||||
registry located at http://www.iana.org/assignments/gmpls-sig- | ||||
parameters: | ||||
Value Type Reference | ||||
----- --------------------------- --------- | ||||
30* Ethernet Virtual Private Line (EVPL) [This document] | ||||
(*) Suggested value. | ||||
It should be noted that the assigned value should be reflected in | ||||
IANAGmplsSwitchingTypeTC at | ||||
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 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. | |||
7. References | 7. References | |||
7.1. Normative References | 7.1. Normative References | |||
[ETH-TRAFFIC] Papadimitriou, D., "Ethernet Traffic Parameters," | [ETH-TRAFFIC] Papadimitriou, D., "Ethernet Traffic Parameters," | |||
draft-ietf-ccamp-ethernet-traffic-parameters-05.txt, | draft-ietf-ccamp-ethernet-traffic-parameters-06.txt, | |||
Work in progress, July 12, 2008. | Work in progress, October 31, 2008. | |||
[GMPLS-EXT] Berger, L., Papadimitriou, P., Fedyk, D., | [GMPLS-EXT] Berger, L., Papadimitriou, P., Fedyk, D., | |||
"Generalized MPLS (GMPLS) Data Channel Switching | "Generalized MPLS (GMPLS) Data Channel Switching | |||
Capable (DCSC) and Channel Set Label Extensions", | Capable (DCSC) and Channel Set Label Extensions", | |||
draft-ietf-ccamp-gmpls-dcsc-channel-ext-00.txt, | draft-ietf-ccamp-gmpls-dcsc-channel-ext-00.txt, | |||
Work in Progress, August 2008. | Work in Progress, August 2008. | |||
[GMPLS-MRN] Papadimitriou, D. et al, "Generalized Multi-Protocol | [GMPLS-MRN] Papadimitriou, D. et al, "Generalized Multi-Protocol | |||
Label Switching (GMPLS) Protocol Extensions for | Label Switching (GMPLS) Protocol Extensions for | |||
Multi-Layer and Multi-Region Networks (MLN/MRN)", | Multi-Layer and Multi-Region Networks (MLN/MRN)", | |||
draft-ietf-ccamp-gmpls-mln-extensions-02.txt, | draft-ietf-ccamp-gmpls-mln-extensions-03.txt, | |||
Work in progress, July 2008. | Work in progress, October 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", | |||
RFC 3471, January 2003. | RFC 3471, January 2003. | |||
[RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label | [RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label | |||
Switching (GMPLS) Signaling - Resource ReserVation | Switching (GMPLS) Signaling - Resource ReserVation | |||
Protocol-Traffic Engineering (RSVP-TE) Extensions", | Protocol-Traffic Engineering (RSVP-TE) Extensions", | |||
RFC 3473, January 2003. | RFC 3473, January 2003. | |||
[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. | |||
[4420BIS] Farrel, A., et al. "Encoding of Attributes for | ||||
Multiprotocol Label Switching (MPLS) Label Switched | ||||
Path (LSP) Establishment Using Resource ReserVation | ||||
Protocol-Traffic Engineering (RSVP-TE)", | ||||
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. | |||
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 services framework", August 2004. | Ethernet services framework", August 2004. | |||
[G.8011.1] ITU-T G.G.8011.1/Y.1307.1, "Ethernet private | [G.8011.1] ITU-T G.G.8011.1/Y.1307.1, "Ethernet private | |||
skipping to change at page 16, line 4 | skipping to change at page 16, line 11 | |||
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 | 9. Author's Addresses | |||
Lou Berger | Lou Berger | |||
LabN Consulting, L.L.C. | LabN Consulting, L.L.C. | |||
Phone: +1-301-468-9228 | Phone: +1-301-468-9228 | |||
Email: lberger@labn.net | Email: lberger@labn.net | |||
Don Fedyk | Don Fedyk | |||
Nortel Networks | Nortel Networks | |||
600 Technology Park Drive | 600 Technology Park Drive | |||
Billerica, MA, 01821 | Billerica, MA, 01821 | |||
Phone: +1-978-288-3041 | Phone: +1-978-288-3041 | |||
Email: dwfedyk@nortel.com | Email: dwfedyk@nortel.com | |||
10. Full Copyright Statement | Generated on: Wed Feb 25 20:00:02 EST 2009 | |||
Copyright (C) The IETF Trust (2008). | ||||
This document is subject to the rights, licenses and restrictions | ||||
contained in BCP 78, and except as set forth therein, the authors | ||||
retain all their rights. | ||||
This document and the information contained herein are provided on an | ||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | ||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND | ||||
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS | ||||
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF | ||||
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | ||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||
11. Intellectual Property | ||||
The IETF takes no position regarding the validity or scope of any | ||||
Intellectual Property Rights or other rights that might be claimed | ||||
to pertain to the implementation or use of the technology | ||||
described in this document or the extent to which any license | ||||
under such rights might or might not be available; nor does it | ||||
represent that it has made any independent effort to identify any | ||||
such rights. Information on the procedures with respect to rights | ||||
in RFC documents can be found in BCP 78 and BCP 79. | ||||
Copies of IPR disclosures made to the IETF Secretariat and any | ||||
assurances of licenses to be made available, or the result of an | ||||
attempt made to obtain a general license or permission for the use | ||||
of such proprietary rights by implementers or users of this | ||||
specification can be obtained from the IETF on-line IPR repository | ||||
at http://www.ietf.org/ipr. | ||||
The IETF invites any interested party to bring to its attention | ||||
any copyrights, patents or patent applications, or other | ||||
proprietary rights that may cover technology that may be required | ||||
to implement this standard. Please address the information to the | ||||
IETF at ietf-ipr@ietf.org. | ||||
Acknowledgement | ||||
Funding for the RFC Editor function is provided by the IETF | ||||
Administrative Support Activity (IASA). | ||||
Generated on: Fri Aug 8 09:53:58 EDT 2008 | ||||
End of changes. 27 change blocks. | ||||
81 lines changed or deleted | 92 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/ |