ietf-corpus

rfc-6002

Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions

L. Berger, D. Fedyk
date2010-10 streamIETF areartg wgccamp statusPROPOSED STANDARD pages10 canonicalhttps://www.rfc-editor.org/rfc/rfc6002 doi10.17487/RFC6002
This document describes two technology-independent extensions to Generalized Multi-Protocol Label Switching (GMPLS). The first extension defines the new switching type Data Channel Switching Capable. Data Channel Switching Capable interfaces are able to support switching of the whole digital channel presented on single channel interfaces. The second extension defines a new type of generalized label and updates related objects. The new label is called the Generalized Channel_Set Label and allows more than one data plane label to be controlled as part of a Label Switched Path (LSP). [STANDARDS-TRACK]

updates

Extracted elements (20)

design-rationale §3

Simple label concatenation as done in RFC 4606 was deemed impractical for communicating multiple VLAN IDs (up to 4096) per LSP, motivating the Generalized Channel_Set Label format. The LABEL_SET object from RFC 3473 served as the foundation, but the new format allows the full set to be represented in a single object rather than requiring multiple objects.

mpls, routing

design-rationale §2

The new switching type was named 'Data Channel Switching Capable' rather than 'port switching' because 'port switching' would collide with the PSC (Packet Switch Capable) acronym. DCSC fills a gap between FSC (fiber) and LSC (wavelength) for port-to-port switching not limited to optical technology.

mpls, routing

interoperability-note §3.4

Transit and egress nodes not supporting the Generalized Channel_Set Label formats will return a PathErr with error code 'Unknown object C_Type' per RFC 3209 upon receiving a Path message with the Generalized Channel_Set LABEL_REQUEST object. Ingress nodes receiving such PathErr must notify the requesting application user.

mpls, routing

interoperability-note §2.1

Transit and egress nodes that do not support the DCSC Switching Type will generate a PathErr message with 'Routing problem/Unsupported Encoding' per RFC 3473 when receiving a Path message with a DCSC Label Request. Ingress nodes receiving such PathErr messages must notify the requesting application user.

mpls, routing

normative-requirement §3.2 MUST NOT

A zero value in the Number of Subchannels field of a LABEL or UPSTREAM_LABEL object indicates that subchannels used in the corresponding direction MUST match subchannels in the reverse direction's label object. The zero value MUST NOT be used in both the LABEL and UPSTREAM_LABEL objects of the same LSP simultaneously.

mpls, routing

normative-requirement §3.2 SHOULD

Make-before-break procedures (see RFC 3209) SHOULD be used when modifying the Channel_Set LABEL object.

mpls, routing

normative-requirement §2 SHOULD

Port labels, as defined in RFC 3471, SHOULD be used for LSPs signaled using the DCSC Switching Type.

mpls, routing

normative-requirement §3.2 SHOULD

Range actions SHOULD be used when possible to minimize the size of the Channel_Set LABEL Object.

mpls, routing

normative-requirement §3.2 MUST

The Generalized Channel_Set LABEL object MUST be used on LSPs that use the Generalized Channel_Set LABEL_REQUEST object, and MUST be processed per RFC 3473.

mpls, routing

normative-requirement §3.2 MUST

The Padding field MUST be included when Subchannel fields in a Channel_Set Subobject result in the subobject not being 32-bit aligned. When present, Padding MUST have a length that results in 32-bit alignment, MUST be set to zero on transmission, and MUST be ignored on receipt. Transit nodes SHOULD pass these bits through unmodified.

mpls, routing

normative-requirement §3.2 MUST

When the number of subchannels required exceeds 1024 (the limit of the 10-bit Number of Subchannels field), multiple Channel_Set Subobjects MUST be used.

mpls, routing

protocol-element §2

Data Channel Switching Capable (DCSC) is a new GMPLS switching type (value 125) for interfaces that switch the whole digital channel on single-channel interfaces. It excludes interfaces that inherently support multiple channels such as WDM or channelized TDM. Examples include concatenated TDM, line-encoded interfaces, and Ethernet switched at the physical port level.

mpls, routing

protocol-element §3.2

The Generalized Channel_Set LABEL object (Class 16, C-Type 4) communicates one or more labels that can all be used equivalently in the data path of a single LSP. It is based on the LABEL_SET object from RFC 3473 but represents the full set in a single object rather than requiring multiple objects.

mpls, routing

protocol-element §3.1

The Generalized Channel_Set LABEL_REQUEST object indicates that the Generalized Channel_Set LABEL object is to be used with the associated LSP. It has the same format as the Generalized LABEL_REQUEST object and uses Class Number 19, C-Type 5.

mpls, routing

protocol-element §3.3

The Generalized Channel_Set LABEL type is applicable to all other label-related objects and subobjects defined in RFC 3473, including SUGGESTED_LABEL, LABEL_SET, ACCEPTABLE_LABEL_SET, UPSTREAM_LABEL, RECOVERY_LABEL, Label ERO subobject, and Label RRO subobject. No new definitions are needed as these objects are label-type agnostic.

mpls, routing

registry §4.3

IANA assigned C-Type 4 ('Generalized Channel_Set') to the existing RSVP_LABEL Object class number (16) in the 'Class Names, Class Numbers, and Class Types' section of the 'RSVP PARAMETERS' registry.

mpls, registry, routing

registry §4.2

IANA assigned C-Type 5 ('Generalized Channel_Set') to the existing LABEL_REQUEST Object class number (19) in the 'Class Names, Class Numbers, and Class Types' section of the 'RSVP PARAMETERS' registry.

mpls, registry, routing

registry §4.1

IANA assigned value 125 to 'Data Channel Switching Capable (DCSC)' in the 'Switching Types' section of the 'GMPLS Signaling Parameters' registry. This value is also reflected in IANAGmplsSwitchingTypeTC of the IANA-GMPLS-TC-MIB.

mpls, registry, routing

security-consideration §5

This document introduces new message object formats for GMPLS signaling (RFC 3473) but does not introduce new signaling messages or change the relationship between adjacent LSRs in the control plane. As such, no additional security considerations are introduced beyond those in RFC 3473 and the MPLS/GMPLS security framework in RFC 5920.

mpls, security, routing

wire-format §3.2

The Generalized Channel_Set LABEL object contains one or more Channel_Set Subobjects. Each subobject has an Action field (8 bits), Number of Subchannels field (10 bits), Label Type field (14 bits), followed by variable-length Subchannel fields and optional Padding. The subobject size MUST be a multiple of 4 bytes and at least 4 bytes.

mpls, routing