draft-ietf-mpls-generalized-rsvp-te-05.txt   draft-ietf-mpls-generalized-rsvp-te-06.txt 
Network Working Group Peter Ashwood-Smith (Nortel Networks Corp.) Network Working Group Peter Ashwood-Smith (Nortel Networks Corp.)
Internet Draft Ayan Banerjee (Calient Networks) Internet Draft Ayan Banerjee (Calient Networks)
Expiration Date: April 2002 Lou Berger (Movaz Networks) Expiration Date: May 2002 Lou Berger (Movaz Networks)
Greg Bernstein (Ciena Corporation) Greg Bernstein (Ciena Corporation)
John Drake (Calient Networks) John Drake (Calient Networks)
Yanhe Fan (Axiowave Networks) Yanhe Fan (Axiowave Networks)
Kireeti Kompella (Juniper Networks, Inc.) Kireeti Kompella (Juniper Networks, Inc.)
Jonathan P. Lang (Calient Networks) Jonathan P. Lang (Calient Networks)
Fong Liaw (Zaffire Inc.) Fong Liaw (Zaffire Inc.)
Eric Mannie (EBONE) Eric Mannie (EBONE)
Ping Pan (Juniper Networks, Inc.) Ping Pan (Juniper Networks, Inc.)
Bala Rajagopalan (Tellium, Inc.) Bala Rajagopalan (Tellium, Inc.)
Yakov Rekhter (Juniper Networks, Inc.) Yakov Rekhter (Juniper Networks, Inc.)
Debanjan Saha (Tellium, Inc.) Debanjan Saha (Tellium, Inc.)
Vishal Sharma (Metanoia, Inc.) Vishal Sharma (Metanoia, Inc.)
George Swallow (Cisco Systems) George Swallow (Cisco Systems)
Z. Bo Tang (Tellium, Inc.) Z. Bo Tang (Tellium, Inc.)
October 2001 November 2001
Generalized MPLS Signaling - RSVP-TE Extensions Generalized MPLS Signaling - RSVP-TE Extensions
draft-ietf-mpls-generalized-rsvp-te-05.txt draft-ietf-mpls-generalized-rsvp-te-06.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-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
skipping to change at page 2, line 8 skipping to change at page 2, line 8
time-division (e.g. SONET ADMs), wavelength (optical lambdas) and time-division (e.g. SONET ADMs), wavelength (optical lambdas) and
spatial switching (e.g. incoming port or fiber to outgoing port or spatial switching (e.g. incoming port or fiber to outgoing port or
fiber). This document presents an RSVP-TE specific description of fiber). This document presents an RSVP-TE specific description of
the extensions. A CR-LDP specific description can be found in the extensions. A CR-LDP specific description can be found in
[GMPLS-LDP]. A generic functional description is presented in [GMPLS-LDP]. A generic functional description is presented in
[GMPLS-SIG]. [GMPLS-SIG].
Contents Contents
1 Introduction ................................................ 4 1 Introduction ................................................ 4
2 Label Related Formats ...................................... 5 2 Label Related Formats ...................................... 4
2.1 Generalized Label Request Object ............................ 5 2.1 Generalized Label Request Object ............................ 4
2.2 Generalized Label Object .................................... 6 2.2 Generalized Label Object .................................... 6
2.3 Waveband Switching .......................................... 7 2.3 Waveband Switching .......................................... 7
2.4 Suggested Label ............................................. 8 2.4 Suggested Label ............................................. 8
2.5 Label Set ................................................... 8 2.5 Label Set ................................................... 8
3 Bidirectional LSPs .......................................... 10 3 Bidirectional LSPs .......................................... 10
3.1 Procedures .................................................. 10 3.1 Procedures .................................................. 10
3.2 Contention Resolution ....................................... 11 3.2 Contention Resolution ....................................... 11
4 Notification ................................................ 11 4 Notification ................................................ 11
4.1 Acceptable Label Set Object ................................. 12 4.1 Acceptable Label Set Object ................................. 11
4.2 Notify Request Objects ...................................... 12 4.2 Notify Request Objects ...................................... 12
4.3 Notify Message .............................................. 14 4.3 Notify Message .............................................. 13
4.4 Removing State with a PathErr message ....................... 15 4.4 Removing State with a PathErr message ....................... 15
5 Explicit Label Control ...................................... 16 5 Explicit Label Control ...................................... 16
5.1 Label ERO subobject ......................................... 17 5.1 Label ERO subobject ......................................... 16
5.2 Label RRO subobject ......................................... 18 5.2 Label RRO subobject ......................................... 18
6 Protection Object ........................................... 19 6 Protection Object ........................................... 19
6.1 Procedures .................................................. 20 6.1 Procedures .................................................. 19
7 Administrative Status Information ........................... 20 7 Administrative Status Information ........................... 19
7.1 Admin Status Object ......................................... 20 7.1 Admin Status Object ......................................... 19
7.2 Path and Resv Message Procedures ............................ 20 7.2 Path and Resv Message Procedures ............................ 20
7.3 Notify Message Procedures ................................... 22 7.3 Notify Message Procedures ................................... 22
8 Control Channel Separation .................................. 23 8 Control Channel Separation .................................. 23
8.1 Interface Identification .................................... 23 8.1 Interface Identification .................................... 23
8.2 Errored Interface Identification ............................ 25 8.2 Errored Interface Identification ............................ 25
9 Fault Handling .............................................. 27 9 Fault Handling .............................................. 26
9.1 Restart_Cap Object .......................................... 27 9.1 Restart_Cap Object .......................................... 27
9.2 Processing of Restart_Cap Object ............................ 28 9.2 Processing of Restart_Cap Object ............................ 27
9.3 Modification to Hello Processing to Support State Recovery .. 28 9.3 Modification to Hello Processing to Support State Recovery .. 28
9.4 Control Channel Faults ...................................... 29 9.4 Control Channel Faults ...................................... 29
9.5 Nodal Faults ................................................ 29 9.5 Nodal Faults ................................................ 29
10 RSVP Message Formats and Handling ........................... 32 10 RSVP Message Formats and Handling ........................... 32
10.1 RSVP Message Formats ........................................ 32 10.1 RSVP Message Formats ........................................ 32
10.2 Addressing Path and PathTear Messages ...................... 34 10.2 Addressing Path and PathTear Messages ...................... 34
11 Acknowledgments ............................................. 35 11 Acknowledgments ............................................. 34
12 Security Considerations ..................................... 35 12 Security Considerations ..................................... 34
13 IANA Considerations ......................................... 35 13 IANA Considerations ......................................... 35
14 References .................................................. 36 14 References .................................................. 36
15 Authors' Addresses .......................................... 37 15 Authors' Addresses .......................................... 37
[Editor's note: changes to be removed prior to publication as an RFC.] [Editor's note: changes to be removed prior to publication as an RFC.]
Changes from previous version: Changes from previous version:
o Revised Admin Status Usage
(per comments and also removed potential race condition)
o Clarified text related to interface bundling
(To be consistent with updated bundling draft.)
o Added IF_ID ERROR_SPEC Object
(Per comments, supports Control Channel Separation by allowing
identification of errored interface.)
o Added U bit to Label RRO subobject
(Per comment, to match defined ERO.)
o Clarified usage of Restart_Cap
o Replaced use of Suggested_Label during recovery with new Recovery_Label
(Per last WG session)
o Added IANA Considerations
o Minor editorial changes and clarifications o Minor editorial changes and clarifications
1. Introduction 1. Introduction
Generalized MPLS extends MPLS from supporting packet (PSC) interfaces Generalized MPLS extends MPLS from supporting packet (PSC) interfaces
and switching to include support of three new classes of interfaces and switching to include support of three new classes of interfaces
and switching: Time-Division Multiplex (TDM), Lambda Switch (LSC) and and switching: Time-Division Multiplex (TDM), Lambda Switch (LSC) and
Fiber-Switch (FSC). A functional description of the extensions to Fiber-Switch (FSC). A functional description of the extensions to
MPLS signaling needed to support the new classes of interfaces and MPLS signaling needed to support the new classes of interfaces and
switching is provided in [GMPLS-SIG]. This document presents RSVP-TE switching is provided in [GMPLS-SIG]. This document presents RSVP-TE
skipping to change at page 6, line 5 skipping to change at page 5, line 39
dynamically established or may be solely administratively controlled. dynamically established or may be solely administratively controlled.
For more information on tunnels and processing of ER hops when using For more information on tunnels and processing of ER hops when using
tunnels see [MPLS-HIERARCHY]. tunnels see [MPLS-HIERARCHY].
Transit and egress nodes MUST verify that the node itself and, where Transit and egress nodes MUST verify that the node itself and, where
appropriate, that the interface or tunnel on which the traffic will appropriate, that the interface or tunnel on which the traffic will
be transmitted can support the requested LSP Encoding Type. If be transmitted can support the requested LSP Encoding Type. If
encoding cannot be supported, the node MUST generate a PathErr encoding cannot be supported, the node MUST generate a PathErr
message, with a "Routing problem/Unsupported Encoding" indication. message, with a "Routing problem/Unsupported Encoding" indication.
Nodes MUST verify that the type indicated in the Switching Type
parameter is supported on the corresponding incoming interface. If
the type cannot be supported, the node MUST generate a PathErr
message with a "Routing problem/Switching Type" indication.
The G-PID parameter is normally only examined at the egress. If the The G-PID parameter is normally only examined at the egress. If the
indicated G-PID cannot be supported then the egress MUST generate a indicated G-PID cannot be supported then the egress MUST generate a
PathErr message, with a "Routing problem/Unsupported L3PID" PathErr message, with a "Routing problem/Unsupported L3PID"
indication. In the case of PSC and when penultimate hop popping indication. In the case of PSC and when penultimate hop popping
(PHP) is requested, the penultimate hop also examines the (stored) G- (PHP) is requested, the penultimate hop also examines the (stored) G-
PID during the processing of the Resv message. In this case if the PID during the processing of the Resv message. In this case if the
G-PID is not supported, then the penultimate hop MUST generate a G-PID is not supported, then the penultimate hop MUST generate a
ResvErr message with a "Routing problem/Unacceptable label value" ResvErr message with a "Routing problem/Unacceptable label value"
indication. The generated ResvErr message MAY include an Acceptable indication. The generated ResvErr message MAY include an Acceptable
Label Set, see Section 4.1. Label Set, see Section 4.1.
skipping to change at page 17, line 39 skipping to change at page 17, line 19
C-Type C-Type
The C-Type of the included Label Object. Copied from the Label The C-Type of the included Label Object. Copied from the Label
Object. Object.
5.1.1. Procedures 5.1.1. Procedures
The Label subobject follows a subobject containing the IP address, or The Label subobject follows a subobject containing the IP address, or
the interface identifier [MPLS-UNNUM], associated with the link on the interface identifier [MPLS-UNNUM], associated with the link on
which it is to be used. The preceding subobject must be a strict which it is to be used. Up to two label subobjects may be present,
object. Up to two label subobjects may be present, one for the one for the downstream label and one for the upstream label. The
downstream label and one for the upstream label. The following following SHOULD result in "Bad EXPLICIT_ROUTE object" errors:
SHOULD result in "Bad EXPLICIT_ROUTE object" errors:
- If the first label subobject is not preceded by a subobject - If the first label subobject is not preceded by a subobject
containing an IP address, or a interface identifier containing an IP address, or a interface identifier
[MPLS-UNNUM], associated with an output link. [MPLS-UNNUM], associated with an output link.
- For a label subobject to follow a subobject that has the L-bit - For a label subobject to follow a subobject that has the L-bit
set set
- On unidirectional LSP setup, for there to be a label subobject - On unidirectional LSP setup, for there to be a label subobject
with the U-bit set with the U-bit set
- For there to be two label subobjects with the same U-bit values - For there to be two label subobjects with the same U-bit values
To support the label subobject, a node must check to see if the To support the label subobject, a node must check to see if the
subobject following its associate address/interface is a label subobject following its associate address/interface is a label
subobject. If it is, one subobject is examined for unidirectional subobject. If it is, one subobject is examined for unidirectional
LSPs and two subobjects for bidirectional LSPs. If the U-bit of the LSPs and two subobjects for bidirectional LSPs. If the U-bit of the
subobject being examined is clear (0), then value of the label is subobject being examined is clear (0), then value of the label is
copied into a new Label_Set object. This Label_Set object MUST be copied into a new Label_Set object. This Label_Set object MUST be
included on the corresponding outgoing Path message. included on the corresponding outgoing Path message.
If the U-bit of the subobject being examined is set (1), then value If the U-bit of the subobject being examined is set (1), then value
of the label is label to be used for upstream traffic associated with of the label is label to be used for upstream traffic associated with
skipping to change at page 25, line 13 skipping to change at page 24, line 35
TLVs. TLVs.
8.1.2. Procedures 8.1.2. Procedures
An IF_ID RSVP_HOP object is used in place of previously defined An IF_ID RSVP_HOP object is used in place of previously defined
RSVP_HOP objects. It is used on links where there is not a one-to- RSVP_HOP objects. It is used on links where there is not a one-to-
one association of a control channel to a data channel, see [GMPLS- one association of a control channel to a data channel, see [GMPLS-
SIG]. The Hop Address and Logical Interface Handle fields are used SIG]. The Hop Address and Logical Interface Handle fields are used
per standard RSVP [RFC2205]. per standard RSVP [RFC2205].
TLVs are used to identify the data channel(s) associated with the TLVs are used to identify the data channel(s) associated with an LSP.
LSP. For a unidirectional LSP, a forward channel MUST be indicated. For a unidirectional LSP, a downstream data channel MUST be
For a bidirectional LSP that uses bundled links, a reverse channel indicated. For bidirectional LSPs, a common downstream and upstream
MUST be indicated. Data channels are specified from the view point data channel is normally indicated. In the special case where a
of the sender of the Path message. The IF_ID RSVP_HOP object SHOULD bidirectional LSP that traverses a bundled link, it is possible to
NOT be used when no TLVs are needed. specify a downstream data channel that differs from the upstream data
channel. Data channels are specified from the view point of the
sender of the Path message. The IF_ID RSVP_HOP object SHOULD NOT be
used when no TLVs are needed.
A node receiving one or more TLVs in a Path message saves their A node receiving one or more TLVs in a Path message saves their
values and returns them in the HOP objects of subsequent Resv values and returns them in the HOP objects of subsequent Resv
messages sent to the node that originated the TLVs. messages sent to the node that originated the TLVs.
As with [MPLS-TE], the node originating an IF_ID object must ensure As with [MPLS-TE], the node originating an IF_ID object must ensure
that the selected outgoing interface is consistent with the outgoing that the selected outgoing interface is consistent with the outgoing
ERO. A node that receives an IF_ID object SHOULD check whether the ERO. A node that receives an IF_ID object SHOULD check whether the
information carried in this object is consistent with the information information carried in this object is consistent with the information
carried in a received ERO, and if not it MUST send a PathErr with the carried in a received ERO, and if not it MUST send a PathErr with the
skipping to change at page 31, line 11 skipping to change at page 30, line 36
defined procedures. defined procedures.
If the MPLS forwarding table entry is found, the appropriate RSVP If the MPLS forwarding table entry is found, the appropriate RSVP
state is created, the entry is bound to the LSP associated with the state is created, the entry is bound to the LSP associated with the
message, and related forwarding state should be considered as valid message, and related forwarding state should be considered as valid
and refreshed. Normal Path message processing should also be and refreshed. Normal Path message processing should also be
conducted. When sending the corresponding outgoing Path message the conducted. When sending the corresponding outgoing Path message the
node SHOULD include a Suggested_Label object with a label value node SHOULD include a Suggested_Label object with a label value
matching the outgoing label from the now restored forwarding entry. matching the outgoing label from the now restored forwarding entry.
The outgoing interface SHOULD also be selected based on the The outgoing interface SHOULD also be selected based on the
forwarding entry. forwarding entry. In the special case where a restarting node also
has a restating downstream neighbor, a Recovery_Label object should
be used instead of a Suggested_Label object.
Additionally, for bidirectional LSPs, the node extracts the label Additionally, for bidirectional LSPs, the node extracts the label
from the UPSTREAM_LABEL object carried in the received Path message, from the UPSTREAM_LABEL object carried in the received Path message,
and searches its MPLS forwarding table for an entry whose outgoing and searches its MPLS forwarding table for an entry whose outgoing
label is equal to the label carried in the object (in the case of label is equal to the label carried in the object (in the case of
link bundling, this may also involved first identifying the link bundling, this may also involved first identifying the
appropriate incoming component link). appropriate incoming component link).
If the MPLS forwarding table entry is not found, the node treats this If the MPLS forwarding table entry is not found, the node treats this
as a setup for a new LSP, and handles it according to previously as a setup for a new LSP, and handles it according to previously
skipping to change at page 36, line 48 skipping to change at page 36, line 24
[MPLS-HIERARCHY] Kompella, K., and Rekhter, Y., "LSP Hierarchy with [MPLS-HIERARCHY] Kompella, K., and Rekhter, Y., "LSP Hierarchy with
MPLS TE", Internet Draft, MPLS TE", Internet Draft,
draft-ietf-mpls-lsp-hierarchy-02.txt, Feb., 2001. draft-ietf-mpls-lsp-hierarchy-02.txt, Feb., 2001.
[MPLS-UNNUM] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links [MPLS-UNNUM] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links
in RSVP-TE", Internet Draft, in RSVP-TE", Internet Draft,
draft-ietf-mpls-rsvp-unnum-02.txt, August 2001 draft-ietf-mpls-rsvp-unnum-02.txt, August 2001
[GMPLS-LDP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling - [GMPLS-LDP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling -
CR-LDP Extensions", Internet Draft, CR-LDP Extensions", Internet Draft,
draft-ietf-mpls-generalized-cr-ldp-01.txt, draft-ietf-mpls-generalized-cr-ldp-05.txt,
February 2001. November 2001.
[GMPLS-SIG] Ashwood-Smith, P. et al, "Generalized MPLS - [GMPLS-SIG] Ashwood-Smith, P. et al, "Generalized MPLS -
Signaling Functional Description", Internet Draft, Signaling Functional Description", Internet Draft,
draft-ietf-mpls-generalized-signaling-02.txt, draft-ietf-mpls-generalized-signaling-07.txt,
February 2001. November 2001.
[PAN-RESTART] Pan, P, et al, "Graceful Restart Mechanism for RSVP-TE", [PAN-RESTART] Pan, P, et al, "Graceful Restart Mechanism for RSVP-TE",
Internet Draft, draft-pan-rsvp-te-restart-01.txt, Internet Draft, draft-pan-rsvp-te-restart-01.txt,
July 2001. July 2001.
[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.
[RFC2205] Braden, R. Ed. et al, "Resource ReserVation Protocol [RFC2205] Braden, R. Ed. et al, "Resource ReserVation Protocol
-- Version 1 Functional Specification", RFC 2205, -- Version 1 Functional Specification", RFC 2205,
skipping to change at line 1665 skipping to change at line 1664
Z. Bo Tang Z. Bo Tang
Tellium, Inc. Tellium, Inc.
2 Crescent Place 2 Crescent Place
P.O. Box 901 P.O. Box 901
Oceanport, NJ 07757-0901 Oceanport, NJ 07757-0901
Phone: +1 732 923 4231 Phone: +1 732 923 4231
Fax: +1 732 923 9804 Fax: +1 732 923 9804
Email: btang@tellium.com Email: btang@tellium.com
Generated on: Mon Oct 1 01:20:20 EDT 2001 Generated on: Wed Nov 21 15:26:44 EST 2001
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/