draft-shiomoto-ccamp-switch-programming-00 74th ietf san francisco march 20091 advice on when it is...

draft-shiomoto-ccamp-switch-programming-0074th IETF San Francisco March 2009 1

Advice on When It is Safe to Start Sending Data on Label Switched Paths Established Using RSVP-TE

draft-shiomoto-ccamp-switch-programming-00.txt

March 2009

Kohei Shiomoto (NTT) and Adrian Farrel (Olddog)

draft-shiomoto-ccamp-switch-programming-00

Purpose of this ID

• Clarifies the RSVP-TE protocol messages exchanges with relation to the programming of cross-connections.– Unidirectional LSP– Bidirectional LSP

• Note: No new procedures or protocol extensions are developed in this ID. See RFC3209, RFC3471, and RFC3473 for the protocol spec.

74th IETF San Francisco March 2009 2


Why is this ID useful?

• To understand when the data can be delivered to the intended destination if control plane is used for LSP setup/teardown.– removing any old, incorrect forwarding instructions

– setting up the cross-connects

• To interpret the performance of LSP setup/teardown [DPPM].

74th IETF San Francisco March 2009


What is spec?MPLS-LSP

• See [RFC3209].• Section 4.1.1.1 describes the processing that

a node does before sending a Resv message to its upstream neighbor. – “The node then sends the new LABEL object as

part of the Resv message to the previous hop. The node SHOULD be prepared to forward packets carrying the assigned label prior to sending the Resv message.”



GMPLS LSP

• Multiple switching technologies– MPLS packet switching networks– Layer two networks (Ethernet, Frame Relay, ATM) – Time-division multiplexing networks (TDM, i.e.,

SONET and SDH)– Wavelength division multiplexing networks (WDM)– Fiber switched network.

• Directionality– Unidirectional– Bidirectional



What is spec?GMPLS LSP (Unidirectional)

• Same as MPLS LSP except for the Suggested_Label.– When Suggested label is used, an ingress node may (safely) start

to transmit data when it receives a label in a Resv message. • Section 3.4 of [RFC3471] states: ... an ingress node should not transmit data traffic on a suggested

label until the downstream node passes a label upstream. • Section 2.5 of [RFC3473] states: ... an ingress node SHOULD NOT transmit data traffic using a

suggested label until the downstream node passes a corresponding label upstream.

• Conclusion– The ingress must not start to transmit traffic until it has both

received a Resv and has programmed its own cross-connect.

74th IETF San Francisco March 2009


GMPLS LSP (Bidirectional)

• Established with one signaling exchange– a Path message from ingress to egress– a Resv from egress to ingress

• Comprised of two sets of forwarding state.– the forward data path– the reverse data path



What is spec?GMPLS LSP (Bidirectional)

• Forward data path– Same as unidirectional LSP

• Backward data path– Upstream_Label object (See Section 3.1 of [RFC3473]).

• An LSR must not wait to receive a Resv message before it programs the cross-connect for the reverse direction data. It must be ready to receive data from the moment that the egress completes processing the Path message that it receives (i.e., before it sends a Resv back upstream).

• An LSR may expect to start receiving reverse direction data as soon as it sends a Path message for a bidirectional LSP.

• An LSR may make some assumptions about the time lag between sending a Path message and the message reaching and being processed by the egress. It may take advantage of this time lag to pipeline programming the cross-connect.



Next step

• Please read the draft.

• The authors wish to get comments to further clarify “when it is safe”.


draft-shiomoto-ccamp-switch-programming-00 74th ietf san francisco march 20091 advice on when it is...

Documents