draft-ietf-ccamp-gmpls-dcsc-channel-ext-01.txt | draft-ietf-ccamp-gmpls-dcsc-channel-ext-02.txt | |||
---|---|---|---|---|
Internet Draft Lou Berger (LabN) | Internet Draft Lou Berger (LabN) | |||
Updates: 3471, 3473, 3945, 4202 Don Fedyk (Nortel) | Updates: 3471, 3473, 3945, 4202 Don Fedyk (Alcatel-Lucent) | |||
Category: Standards Track | Category: Standards Track | |||
Expiration Date: August 25, 2009 | Expiration Date: April 14, 2010 | |||
February 25, 2009 | October 14, 2009 | |||
Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and | Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and | |||
Channel Set Label Extensions | Channel Set Label Extensions | |||
draft-ietf-ccamp-gmpls-dcsc-channel-ext-01.txt | draft-ietf-ccamp-gmpls-dcsc-channel-ext-02.txt | |||
Status of this Memo | Status of this Memo | |||
This Internet-Draft is submitted to IETF in full conformance with the | This Internet-Draft is submitted to IETF in full conformance with the | |||
provisions of BCP 78 and BCP 79. | 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 BCP 78 and BCP 79. | aware will be disclosed, in accordance with BCP 78 and BCP 79. | |||
skipping to change at page 1, line 40 | skipping to change at page 1, line 40 | |||
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 August 25, 2009. | This Internet-Draft will expire on April 14, 2010. | |||
Copyright and License Notice | Copyright and License Notice | |||
Copyright (c) 2009 IETF Trust and the persons identified as the | Copyright (c) 2009 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 | Provisions Relating to IETF Documents in effect on the date of | |||
(http://trustee.ietf.org/license-info) in effect on the date of | publication of this document (http://trustee.ietf.org/license-info). | |||
publication of this document. Please review these documents | Please review these documents carefully, as they describe your rights | |||
carefully, as they describe your rights and restrictions with respect | and restrictions with respect to this document. | |||
to this document. | ||||
Abstract | Abstract | |||
This document describes two technology-independent extensions to | This document describes two technology-independent extensions to | |||
Generalized Multi-Protocol Label Switching. The first extension | Generalized Multi-Protocol Label Switching. The first extension | |||
defines the new switching type Data Channel Switching Capable. Data | defines the new switching type Data Channel Switching Capable. Data | |||
Channel Switching Capable interfaces are able to support switching of | Channel Switching Capable interfaces are able to support switching of | |||
the whole digital channel presented on single channel interfaces. | the whole digital channel presented on single channel interfaces. | |||
The second extension defines a new type of generalized label and | The second extension defines a new type of generalized label and | |||
updates related objects. The new label is called the Generalized | updates related objects. The new label is called the Generalized | |||
skipping to change at page 3, line 15 | skipping to change at page 3, line 15 | |||
1. Introduction | 1. Introduction | |||
This document describes two technology independent extensions to | This document describes two technology independent extensions to | |||
Generalized Multi-Protocol Label Switching (GMPLS). Both of these | Generalized Multi-Protocol Label Switching (GMPLS). Both of these | |||
extensions were initially defined to in the context of Ethernet | extensions were initially defined to in the context of Ethernet | |||
services, see [GMPLS-ESVCS] and [GMPLS-MEF-UNI], but are generic in | services, see [GMPLS-ESVCS] and [GMPLS-MEF-UNI], but are generic in | |||
nature and may be useful to any switching technology controlled via | nature and may be useful to any switching technology controlled via | |||
GMPLS. | GMPLS. | |||
The first extension defines a new switching type, which is called | The first extension defines a new switching type, which is called | |||
Data Channel Switching Capable, or DCSC. DCSC interfaces are able to | Data Channel Switching Capable (DCSC). DCSC interfaces are able to | |||
support switching of the whole digital channel presented on single | support switching of the whole digital channel presented on single | |||
channel interfaces. The second extension defines a new type of | channel interfaces. The second extension defines a new type of | |||
generalized label and updates related objects. The new label is | generalized label and updates related objects. The new label is | |||
called the Generalized Channel_Set Label and allows more than one | called the Generalized Channel_Set Label and allows more than one | |||
data plane label to be controlled as part of an LSP. | data plane label to be controlled as part of an LSP. | |||
1.1. Conventions used in this document | 1.1. 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. Data Channel Switching | 2. Data Channel Switching | |||
Current GMPLS switching types are defined in [RFC3945] and [RFC3471] | Current GMPLS switching types are defined in [RFC3945] and [RFC3471] | |||
and support switching at the packet (PSC), frame (L2SC), time-slot | and support switching at the packet (PSC), frame (L2SC), time-slot | |||
(TDM), frequency (LSC) and fiber (FSC) granularities. One type of | (TDM), frequency (LSC) and fiber (FSC) granularities. One type of | |||
switching that is not well represented in this current set is | switching that is not well represented in this current set is | |||
switching that occurs of the when all data received on an ingress | switching that occurs when all data received on an ingress port is | |||
port is switched through a network to an egress port. While there | switched through a network to an egress port. While there are | |||
are similarities between this level of switching and the "opaque | similarities between this level of switching and the "opaque single | |||
single wavelength" case described in Section 3.5 of [RFC4202], such | wavelength" case described in Section 3.5 of [RFC4202], such port-to- | |||
port-to-port switching is not limited to the optical switching | port switching is not limited to the optical switching technology | |||
technology implied by the LSC type. FSC is also similar, but it is | implied by the LSC type. FSC is also similar, but it is restricted to | |||
restricted to fiber ports and also supports multiple data channels | fiber ports and also supports multiple data channels with-in the | |||
with in the fiber port. | fiber port. | |||
This document defines the new switching type called Data Channel | This document defines the new switching type called Data Channel | |||
Switching Capable (DCSC). (Port switching seems a more intuitive | Switching Capable (DCSC). Port switching seems a more intuitive name, | |||
name, but it collides with PSC so isn't used.) DCSC interfaces are | but this naming collides with PSC so it isn't used. DCSC interfaces | |||
able to support switching of the whole digital channel presented on | are able to support switching of the whole digital channel presented | |||
single channel interfaces. Interfaces that inherently support | on single channel interfaces. Interfaces that inherently support | |||
multiple channels, e.g., WDM and channelized TDM interfaces, are | multiple channels, e.g., WDM and channelized TDM interfaces, are | |||
specifically excluded from this type. Any interface that can be | specifically excluded from this type. Any interface that can be | |||
represented as a single digital channel are included. Examples | represented as a single digital channel are included. Examples | |||
include concatenated TDM and line encoded interfaces. Framed | include concatenated TDM and line encoded interfaces. Framed | |||
interfaces may also be included when they support switching on an | interfaces may also be included when they support switching on an | |||
interface granularity. | interface granularity. | |||
DCSC is represented in GMPLS, see [RFC3471] and [RFC4202], using the | DCSC is represented in GMPLS, see [RFC3471] and [RFC4202], using the | |||
value TBA (by IANA). | value TBA (by IANA). | |||
Port labels, as defined in [RFC3471], SHOULD be used for LSPs | Port labels, as defined in [RFC3471], SHOULD be used for LSPs | |||
signaled using the DCSC Switching Type. The DCSC Switching Type may | signaled using the DCSC Switching Type. The DCSC Switching Type may | |||
be used with wither the in the Generalized Label Request object, | be used with the Generalized Label Request object, [RFC3473], or the | |||
[RFC3473], or the Generalized Channel_Set LABEL_REQUEST Object | Generalized Channel_Set LABEL_REQUEST Object defined below. | |||
defined below. | ||||
2.1. Compatibility | 2.1. Compatibility | |||
Transit and egress nodes that do not support the DCSC Switching Type | Transit and egress nodes that do not support the DCSC Switching Type | |||
which received a Path message with a Label Request containing the | when receiving a Path message with a Label Request containing the | |||
DCSC Switching Type will behave in the same way nodes generally | DCSC Switching Type will behave in the same way nodes generally | |||
handle the case of an unsupported Switching Type. Specifically, per | handle the case of an unsupported Switching Type. Specifically, per | |||
[RFC3473], such nodes are required to generate a PathErr message, | [RFC3473], such nodes are required to generate a PathErr message, | |||
with a "Routing problem/Unsupported Encoding" indication. | with a "Routing problem/Unsupported Encoding" indication. | |||
Ingress nodes initiating a Path message containing a Label Request | Ingress nodes initiating a Path message containing a Label Request | |||
containing the DCSC Switching Type should receive such PathErr | containing the DCSC Switching Type, receiving such a PathErr | |||
messages, and can then notify the requesting application user as | messages, then notify the requesting application user as appropriate. | |||
appropriate. | ||||
3. Generalized Channel_Set Label Related Formats | 3. Generalized Channel_Set Label Related Formats | |||
This section defines a new type of generalized label and updates | This section defines a new type of generalized label and updates | |||
related objects. This section updates the label related definitions | related objects. This section updates the label related definitions | |||
of [RFC3473]. The ability to communicate more than one label as part | of [RFC3473]. The ability to communicate more than one label as part | |||
of the same LSP was motivated by the support for the communication of | of the same LSP was motivated by the support for the communication of | |||
one or more VLAN IDs. Simple concatenation of labels as is done in | one or more VLAN IDs. Simple concatenation of labels as is done in | |||
[RFC4606] was deemed impractical given the large number of VLAN IDs | [RFC4606] was deemed impractical given the large number of VLAN IDs | |||
(up to 4096) that may need to be communicated. The formats defined | (up to 4096) that may need to be communicated. The formats defined | |||
in this section are not technology specific and may be useful for | in this section are not technology specific and may be useful for | |||
other switching technologies. The LABEL_SET object defined in | other switching technologies. The LABEL_SET object defined in | |||
[RFC3473] serves as the foundation for the defined formats. | [RFC3473] serves as the foundation for the defined formats. | |||
3.1. Generalized Channel_Set LABEL_REQUEST Object | 3.1. Generalized Channel_Set LABEL_REQUEST Object | |||
The Generalized Channel_Set LABEL_REQUEST object is used to indicate | The Generalized Channel_Set LABEL_REQUEST object is used to indicate | |||
that the Generalized Channel_Set LABEL Object is to be used with the | that the Generalized Channel_Set LABEL Object is to be used with the | |||
associated LSP. The format of the Generalized Channel_Set | associated LSP. The format of the Generalized Channel_Set | |||
LABEL_REQUEST object is the same as the Generalized LABEL_REQUEST | LABEL_REQUEST object is the same as the Generalized LABEL_REQUEST | |||
object and uses of C-Type of TBA. | object and uses a C-Type of TBA. | |||
3.2. Generalized Channel_Set LABEL Object | 3.2. Generalized Channel_Set LABEL Object | |||
The Generalized Channel_Set LABEL Object communicates one or more | The Generalized Channel_Set LABEL Object communicates one or more | |||
labels, all of which can be used equivalently in the data path | labels, all of which can be used equivalently in the data path | |||
associated with a single LSP. The format of the Generalized | associated with a single LSP. The format of the Generalized | |||
Channel_Set LABEL Object is based on the LABEL_SET object defined in | Channel_Set LABEL Object is based on the LABEL_SET object defined in | |||
[RFC3473]. It differs from the the LABEL_SET object in that the full | [RFC3473]. It differs from the the LABEL_SET object in that the full | |||
set may be represented in a single object rather than the multiple | set may be represented in a single object rather than the multiple | |||
objects required by the [RFC3473] LABEL_SET object. The object MUST | objects required by the [RFC3473] LABEL_SET object. The object MUST | |||
skipping to change at page 7, line 34 | skipping to change at page 7, line 34 | |||
Generalized Channel_Set Sub-Object result in the Sub-Object not | Generalized Channel_Set Sub-Object result in the Sub-Object not | |||
being 32 bit aligned. When present, the Padding field MUST | being 32 bit aligned. When present, the Padding field MUST | |||
have a length that results in the Sub-Object being 32 bit | have a length that results in the Sub-Object being 32 bit | |||
aligned. When present, the Padding field MUST be set to a zero | aligned. When present, the Padding field MUST be set to a zero | |||
(0) value on transmission and MUST be ignored on receipt. | (0) value on transmission and MUST be ignored on receipt. | |||
These bits SHOULD be passed through unmodified by transit | These bits SHOULD be passed through unmodified by transit | |||
nodes. | nodes. | |||
3.3. Other Label related Objects | 3.3. Other Label related Objects | |||
The previous section introduces a new LABEL object. As such the | The previous section introduced a new LABEL object. As such the | |||
formats of the other label related objects are also impacted. | formats of the other label related objects are also impacted. | |||
Processing of these objects is not modified and remain per their | Processing of these objects is not modified and remains per their | |||
respective specifications. The other label related objects are | respective specifications. The other label related objects are | |||
defined in [RFC3473] and include: | defined in [RFC3473] and include: | |||
- SUGGESTED_LABEL object | - SUGGESTED_LABEL object | |||
- LABEL_SET object | - LABEL_SET object | |||
- ACCEPTABLE_LABEL_SET object | - ACCEPTABLE_LABEL_SET object | |||
- UPSTREAM_LABEL object | - UPSTREAM_LABEL object | |||
- RECOVERY_LABEL object | - RECOVERY_LABEL object | |||
3.4. Compatibility | 3.4. Compatibility | |||
Transit and egress nodes that do not support the Generalized | Transit and egress nodes that do not support the Generalized | |||
Channel_Set Label related formats will first receive a Path message | Channel_Set Label related formats will first receive a Path message | |||
containing Generalized Channel_Set LABEL_REQUEST object. When a such | containing Generalized Channel_Set LABEL_REQUEST object. When such a | |||
a node receives the Path message, per [RFC3209], it will sends a | node receives the Path message, per [RFC3209], it will send a PathErr | |||
PathErr with the error code "Unknown object C_Type" . | with the error code "Unknown object C_Type". | |||
Ingress nodes initiating a Path message containing a Generalized | Ingress nodes initiating a Path message containing a Generalized | |||
Channel_Set LABEL_REQUEST object should receive such PathErr | Channel_Set LABEL_REQUEST object on receiving such a PathErr | |||
messages, and can then notify the requesting application user as | messages, then notify the requesting application user as appropriate. | |||
appropriate. | ||||
4. IANA Considerations | 4. IANA Considerations | |||
IANA is requested to administer assignment of new values for | IANA is requested to administer assignment of new values for | |||
namespaces defined in this document and reviewed in this section. | namespaces defined in this document and summarized in this section. | |||
4.1. Data Channel Switching Type | 4.1. Data Channel Switching Type | |||
Upon approval of this document, the IANA will make the assignment in | Upon approval of this document, IANA will make the assignment in the | |||
the "Switching Types" section of the "GMPLS Signaling Parameters" | "Switching 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 | |||
----- --------------------------- --------- | ----- --------------------------- --------- | |||
125* Data Channel Switching Capable (DCSC) [This document] | 125* Data Channel Switching Capable (DCSC) [This document] | |||
(*) Suggested value. | (*) Suggested value. | |||
It should be noted that the assigned value should be reflected in | It should be noted that the assigned value should be reflected in | |||
IANAGmplsSwitchingTypeTC at | IANAGmplsSwitchingTypeTC at | |||
http://www.iana.org/assignments/ianagmplstc-mib. | http://www.iana.org/assignments/ianagmplstc-mib. | |||
4.2. Generalized Channel_Set LABEL_REQUEST Object | 4.2. Generalized Channel_Set LABEL_REQUEST Object | |||
Upon approval of this document, the IANA will make the assignment in | Upon approval of this document, IANA will make the assignment in the | |||
the "Class Names, Class Numbers, and Class Types" section of the | "Class Names, Class Numbers, and Class Types" section of the "RSVP | |||
"RSVP PARAMETERS" registry located at | PARAMETERS" registry located at http://www.iana.org/assignments/rsvp- | |||
http://www.iana.org/assignments/rsvp-parameters. | parameters. | |||
A new class type for the existing LABEL_REQUEST Object class number | A new class type for the existing LABEL_REQUEST Object class number | |||
(19) with the following definition: | (19) with the following definition: | |||
Class Types or C-Types: | Class Types or C-Types: | |||
5* Generalized Channel_Set [This document] | 5* Generalized Channel_Set [This document] | |||
(*) Suggested value. | (*) Suggested value. | |||
4.3. Generalized Channel_Set LABEL Object | 4.3. Generalized Channel_Set LABEL Object | |||
Upon approval of this document, the IANA will make the assignment in | Upon approval of this document, IANA will make the assignment in the | |||
the "Class Names, Class Numbers, and Class Types" section of the | "Class Names, Class Numbers, and Class Types" section of the "RSVP | |||
"RSVP PARAMETERS" registry located at | PARAMETERS" registry located at http://www.iana.org/assignments/rsvp- | |||
http://www.iana.org/assignments/rsvp-parameters. | parameters. | |||
A new class type for the existing RSVP_LABEL Object class number (16) | A new class type for the existing RSVP_LABEL Object class number (16) | |||
with the following definition: | with the following definition: | |||
Class Types or C-Types: | Class Types or C-Types: | |||
4* Generalized Channel_Set [This document] | 4* Generalized Channel_Set [This document] | |||
(*) Suggested value. | (*) Suggested value. | |||
skipping to change at page 10, line 28 | skipping to change at page 10, line 28 | |||
[RFC3945] Mannie, E., Editor, "Generalized Multi-Protocol Label | [RFC3945] Mannie, E., Editor, "Generalized Multi-Protocol Label | |||
Switching (GMPLS) Architecture", RFC 3945, October | Switching (GMPLS) Architecture", RFC 3945, October | |||
2004. | 2004. | |||
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing | [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing | |||
Extensions in Support of Generalized Multi-Protocol | Extensions in Support of Generalized Multi-Protocol | |||
Label Switching (GMPLS)", RFC 4202, October 2005. | Label Switching (GMPLS)", RFC 4202, October 2005. | |||
6.2. Informative References | 6.2. Informative References | |||
[GMPLS-ESVCS] Berger, L., Papadimitriou, P., Fedyk, D., | [GMPLS-ESVCS] Berger, L., Fedyk, D., "Generalized MPLS (GMPLS) | |||
"Generalized MPLS (GMPLS) Support For Metro Ethernet | Support For Metro Ethernet Forum and G.8011 Ethernet | |||
Forum and G.8011 Ethernet Service Switching", Work in | Service Switching", Work in Progress, | |||
Progress, draft-ietf-ccamp-gmpls-ether-svcs-02.txt, | draft-ietf-ccamp-gmpls-ether-svcs. | |||
August 2008. | ||||
[GMPLS-MEF-UNI] Berger, L., Papadimitriou, P., Fedyk, D., | [GMPLS-MEF-UNI] Berger, L., Fedyk, D., "Generalized MPLS (GMPLS) | |||
"Generalized MPLS (GMPLS) Support For Metro | Support For Metro Ethernet Forum and G.8011 | |||
Ethernet Forum and G.8011 User-Network Interface | User-Network Interface (UNI)", Work in Progress, | |||
(UNI)", Work in Progress, | draft-ietf-ccamp-gmpls-mef-uni. | |||
draft-ietf-ccamp-gmpls-mef-uni-01.txt, | ||||
August 2008. | ||||
[MPLS-SEC] Fang, L., et al, "Security Framework for MPLS and | [MPLS-SEC] Fang, L., et al, "Security Framework for MPLS and | |||
GMPLS Networks", Work in Progress, | GMPLS Networks", Work in Progress, | |||
draft-ietf-mpls-mpls-and-gmpls-security-framework-04.txt, | draft-ietf-mpls-mpls-and-gmpls-security-framework. | |||
November 2008. | ||||
[RFC4606] Mannie, E., et al "Generalized Multi-Protocol Label | [RFC4606] Mannie, E., et al "Generalized Multi-Protocol Label | |||
Switching (GMPLS) Extensions for Synchronous Optical | Switching (GMPLS) Extensions for Synchronous Optical | |||
Network (SONET) and Synchronous Digital Hierarchy (SDH) | Network (SONET) and Synchronous Digital Hierarchy (SDH) | |||
Control", RFC 4606, August 2006. | Control", RFC 4606, August 2006. | |||
7. Acknowledgments | 7. 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. | |||
skipping to change at page 11, line 21 | skipping to change at page 11, line 21 | |||
Adrian Farrel for their valuable comments. | Adrian Farrel for their valuable comments. | |||
8. Author's Addresses | 8. 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 | Alcatel-Lucent | |||
600 Technology Park Drive | Groton, MA, 01450 | |||
Billerica, MA, 01821 | Phone: +1-978-467-5645 | |||
Phone: +1-978-288-3041 | Email: donald.fedyk@alcatel-lucent.com | |||
Email: dwfedyk@nortel.com | ||||
Generated on: Wed Feb 25 20:00:22 EST 2009 | Generated on: Wed Oct 14 14:46:36 EDT 2009 | |||
End of changes. 26 change blocks. | ||||
68 lines changed or deleted | 59 lines changed or added | |||
This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |