ietf-corpus

rfc-3038

VCID Notification over ATM link for LDP

K. Nagami, Y. Katsube, N. Demizu, H. Esaki, P. Doolan
date2001-01 streamIETF areartg wgmpls statusPROPOSED STANDARD pages19 canonicalhttps://www.rfc-editor.org/rfc/rfc3038 doi10.17487/RFC3038
This document specifies the procedures for the communication of VCID values between neighboring ATM-LSRs that must occur in order to ensure this property. [STANDARDS-TRACK]

updated by

Extracted elements (25)

design-rationale §1

ATM VPI and VCI labels are rewritten with new values at every switch node through which a VC passes and cannot provide end-to-end identification of a VC. The VCID concept was introduced so that LDP mapping messages can carry a stable VC identifier that has the same value at both ends of the VC.

mpls

design-rationale §3.2

BLLI values are unique at the sender node but not at the receiver node, because multiple sender nodes may independently allocate the same BLLI value. Therefore, the receiver must identify a BLLI notification by the combination of BLLI value and sender ATM address (both carried in SETUP and ADD_PARTY signaling messages).

mpls

design-rationale §3.1.1

The 3-way handshake (VCID PROPOSE → VCID ACK → LDP REQUEST) is required because the transmission of the VCID PROPOSE message over the new VC is unreliable. The LDP REQUEST from node A serves as confirmation that the ACK was received correctly.

mpls

design-rationale §4

VCI=32 (used for unlabeled packet transfer) is explicitly excluded from VPID notification so that the same encapsulation method can be applied uniformly to both VPID procedure messages and inband VCID procedure messages. VCI=33 and VCI=34 are used instead.

mpls

design-rationale §2.1

VCID notification procedures are categorized as inband (messages forwarded over the VC to which they refer) or outband (messages forwarded over a different connection). The choice of procedure depends on the VC type (transparent point-to-point, VP, PVC, or SVC) and the signaling capabilities available.

mpls

interoperability-note §2.1

When an LSP uses a point-to-multipoint VC and an ATM switch in an LSR is not capable of VC merge, adding a new leaf may require temporarily splitting the active LSP to send an inband VCID PROPOSE notification, causing potential performance and QoS impact.

mpls

normative-requirement §3.2.2 MUST

For outband notification with small-sized field on point-to-multipoint VCs, the BLLI value used in ADD_PARTY must be the same value as that used to establish the first point-to-point VC of the tree, and the upstream root node determines this value.

mpls

normative-requirement §3.1.1 MUST

Once the 3-way handshake completes, node B must ignore all VCID PROPOSE messages received over the VC. If node A does not receive an ACK with the expected message ID and VCID within a given period, it must resend the VCID PROPOSE message.

mpls

normative-requirement §3.2 MUST NOT

The BLLI value of a new VC must not be assigned to other VCs during the VCID notification procedure to avoid identifier conflicts. Once the VCID/BLLI association is established, the BLLI value may be reused for a new VC.

mpls

normative-requirement §3.1.1 MUST NOT

Until node B receives the LDP Label Request message, node B must discard any packet received over the new VC other than the VCID PROPOSE message.

mpls

protocol-element §2.1

A transparent point-to-point link requires no VCID notification because the VPI/VCI label is the same at each end. For VP links, inband notification, VPID notification, or no notification may be used. PVCs always use inband notification. SVCs may use outband, outband with small-sized field, or inband notification.

mpls

protocol-element §1

A Virtual Connection Identifier (VCID) is a stable identifier assigned to an ATM VC that retains the same value at both ends of the VC, enabling use in LDP label mapping messages where ATM VPI/VCI labels cannot serve this purpose.

mpls

protocol-element §3.1.2

For point-to-multipoint VCs, VCID notification is defined for future use (current LDP does not support multicast). When adding a new leaf, the existing VCID already assigned to the VC is reused; downstream nodes that have already received the LDP REQUEST must discard any new VCID PROPOSE.

mpls

protocol-element §3.2

Outband notification using a small-sized field uses the 7-bit BLLI (Broadband Low Layer Information) user-specific field in ATM Forum UNI 3.1/4.0 SETUP messages as a temporary identifier during VCID notification when no field large enough to carry a full VCID is available.

mpls

protocol-element §4

The VPID notification procedure assigns a shared VP Identifier (VPID) for each direction of a VP link. After VPID notification completes, the VCID of any VC within that VP is constructed as VPID (MSB) concatenated with the VCI (LSB), eliminating the need for a separate per-VC VCID notification.

mpls

protocol-element §2.2

VC directionality governs VCID procedures: the VCID procedure for a VC is always triggered from the upstream node. Bidirectional label-switched VCs require two VCID procedures (one per direction); unidirectional VCs require only one.

mpls

security-consideration §Security Considerations

This document does not introduce new security issues beyond those already present in LDP. Implementations may reuse the same security mechanisms proposed for LDP to protect VCID notification messages.

mpls, security

state-machine §3.1.1

Inband point-to-point VCID notification uses a 3-way handshake: upstream node A sends VCID PROPOSE through the new VC; node B replies with VCID ACK over the LDP VC; node A then sends an LDP Label Request, after which node B sends an LDP Label Mapping. The handshake states are: VC established, PROPOSE sent, ACK received, REQUEST sent, MAPPING received.

mpls

wire-format §5.1.3

VCID ACK Message (type 0x0503) and VCID NACK Message (type 0x0504): LDP fixed header, 32-bit Message ID, Label TLV echoing the proposed VCID (type 0x0203), and a VCID Message ID field echoing the proposer's message ID. Sent as TCP packets over the LDP session.

mpls

wire-format §5.2.1

VCID Label TLV (type 0x0203): 16-bit type with U and F bits, 16-bit Length, and a 4-byte VCID value. Used in all VCID PROPOSE, ACK, and NACK messages to carry the virtual connection identifier.

mpls

wire-format §5.2.2

VCID Message ID TLV (type 0x0701): 16-bit type with U and F bits, 16-bit Length, and a 4-byte VCID Message ID value. Carried in ACK and NACK messages to correlate responses back to the originating PROPOSE message.

mpls

wire-format §5.1.1

VCID Propose Inband Message (type 0x0501): LDP fixed header with U bit, 16-bit message type, 16-bit Message Length, 32-bit Message ID, Label TLV (type 0x0203) carrying the VCID value, and optional parameters. Sent as null-encapsulation packet with label stack header using reserved label value 4.

mpls

wire-format §5.1.2

VCID Propose Message (type 0x0502): LDP fixed header, 32-bit Message ID, Label TLV (VCID, type 0x0203), Temporary ID TLV (type 0x0702, carrying the 7-bit BLLI user-specific field), and optional parameters. Sent over the LDP VC for outband-small-field notification.

mpls

wire-format §5.2.3

VCID Temporary ID TLV (type 0x0702): 16-bit type, 16-bit Length, and a 1-byte Temporary ID field carrying the user-specific value from the BLLI IE Layer 3 protocol field in ATM Forum UNI 3.1/4.0 signaling.

mpls

wire-format §5.2.4

VPID Label TLV (type 0x0703): 16-bit type with U and F bits, 16-bit Length, and a 2-byte VPID value. Used in VPID PROPOSE inband (0x0505), VPID ACK (0x0506), and VPID NACK (0x0507) messages.

mpls