--- 1/draft-ietf-mpls-generalized-cr-ldp-01.txt 2006-02-05 00:38:56.000000000 +0100 +++ 2/draft-ietf-mpls-generalized-cr-ldp-02.txt 2006-02-05 00:38:56.000000000 +0100 @@ -1,113 +1,113 @@ Network Working Group Peter Ashwood-Smith (Nortel Networks Corp.) Internet Draft Ayan Banerjee (Calient Networks) -Expiration Date: September 2001 Lou Berger (Movaz Networks) +Expiration Date: October 2001 Lou Berger (Movaz Networks) Greg Bernstein (Ciena Corporation) John Drake (Calient Networks) Yanhe Fan (Axiowave Networks) Kireeti Kompella (Juniper Networks, Inc.) Eric Mannie (EBONE) Jonathan P. Lang (Calient Networks) Bala Rajagopalan (Tellium, Inc.) Yakov Rekhter (Juniper Networks, Inc.) Debanjan Saha (Tellium, Inc.) Vishal Sharma (Jasmine Networks) George Swallow (Cisco Systems) Z. Bo Tang (Tellium, Inc.) - March 2001 + April 2001 Generalized MPLS Signaling - CR-LDP Extensions - draft-ietf-mpls-generalized-cr-ldp-01.txt + draft-ietf-mpls-generalized-cr-ldp-02.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - To view the current status of any Internet-Draft, please check the - "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow - Directory, see http://www.ietf.org/shadow.html. + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. Abstract This document describes extensions to CR-LDP signaling required to support Generalized MPLS. Generalized MPLS extends MPLS to encompass time-division (e.g. SONET ADMs), wavelength (optical lambdas) and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). This document presents a CR-LDP specific description of the extensions. An RSVP-TE specific description can be found in [GMPLS- RSVP]. A generic functional description is presented in [GMPLS-SIG]. Contents 1 Introduction .............................................. 3 2 Label Related Formats .................................... 3 - 2.1 Generalized Label Request ................................. 4 - 2.1.1 Generalized Label Request with SONET/SDH Label Range ...... 4 - 2.1.2 Procedures ................................................ 4 - 2.1.3 Bandwidth Encoding ........................................ 5 - 2.2 Generalized Label ......................................... 6 - 2.2.1 Procedures ................................................ 6 + 2.1 Generalized Label Request ................................. 3 + 2.1.1 Procedures ................................................ 4 + 2.1.2 Bandwidth Encoding ........................................ 5 + 2.2 Generalized Label ......................................... 5 + 2.2.1 Procedures ................................................ 5 2.3 Waveband Switching ........................................ 6 - 2.3.1 Procedures ................................................ 7 - 2.4 Suggested Label ........................................... 8 - 2.5 Label Set ................................................. 8 - 2.5.1 Procedures ................................................ 8 - 3 Bidirectional LSPs ........................................ 9 - 3.1 Procedures ................................................ 10 - 4 Explicit Label Control .................................... 10 - 4.1 Procedures ................................................ 11 - 5 Protection TLV ............................................ 12 - 5.1 Procedures ................................................ 12 - 6 Acknowledgments ........................................... 12 - 7 Security Considerations ................................... 13 - 8 References ................................................ 13 - 9 Authors' Addresses ........................................ 13 + 2.3.1 Procedures ................................................ 6 + 2.4 Suggested Label ........................................... 7 + 2.5 Label Set ................................................. 7 + 2.5.1 Procedures ................................................ 7 + 3 Bidirectional LSPs ........................................ 8 + 3.1 Procedures ................................................ 9 + 4 Notification on Label Error ............................... 9 + 5 Explicit Label Control .................................... 10 + 5.1 Procedures ................................................ 10 + 6 Protection TLV ............................................ 11 + 6.1 Procedures ................................................ 12 + 7 Acknowledgments ........................................... 12 + 8 Security Considerations ................................... 12 + 9 References ................................................ 12 +10 Authors' Addresses ........................................ 13 Changes from previous version: -o Revised label request -o Moved protection flags to separate object -o Minor text cleanup +o Removed SONET/SDH specifics. +o Added Acceptable Label Set 1. Introduction Generalized MPLS extends MPLS from supporting packet (PSC) interfaces and switching to include support of three new classes of interfaces and switching: Time-Division Multiplex (TDM), Lambda Switch (LSC) and Fiber-Switch (FSC). A functional description of the extensions to MPLS signaling needed to support the new classes of interfaces and switching is provided in [GMPLS-SIG]. This document presents CR-LDP specific formats and mechanisms needed to support all four classes of interfaces. RSVP-TE extensions can be found in [GMPLS-RSVP]. [GMPLS-SIG] should be viewed as a companion document to this document. The format of this document parallels [GMPLS-SIG]. It should be noted that the RSVP-TE specific version of Generalized MPLS includes RSVP specific support for rapid failure notification, see Section 4 [GMPLS-RSVP]. For CR-LDP there is not currently a similar mechanism. When a failure is detected it will be propagated with RELEASE/WITHDRAW messages radially outward from the point of failure. Resources are to be released in this phase and actual resource - information is fed back to the source using the feedback mechanisms - of [FEEDBACK]. In this manner the source will have an accurate view - of available resources and can start rerouting much sooner. + information may be fed back to the source using a feedback + mechanisms. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Label Related Formats This section defines formats for a generalized label request, a generalized label, support for waveband switching, suggested label and label sets. @@ -124,38 +124,21 @@ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| 0x0901 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP Enc. Type | Reserved | G-PID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ See [GMPLS-SIG] for a description of parameters. -2.1.1. Generalized Label Request with SONET/SDH Label Range - - The format of a Generalized Label Request with SONET/SDH label range - (in CR-LDP) is: - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |U|F| 0x0902 | Length | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | LSP Enc. Type | Reserved | G-PID | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | RNC | Signal Type |Rsrved.| RGT | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - See [GMPLS-SIG] for a description of parameters. - -2.1.2. Procedures +2.1.1. Procedures A node processing a REQUEST message containing a Generalized Label Request must verify that the requested parameters can be satisfied by the incoming interface, the node and by the outgoing interface. The node may either directly support the LSP or it may use a tunnel (FA), i.e., another class of switching. In either case, each parameter must be checked. Note that local node policy dictates when tunnels may be used and when they may be created. Local policy may allow for tunnels to be @@ -170,28 +153,29 @@ problem/Unsupported Encoding" indication. 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 NOTIFICATION message, with a "Routing problem/Unsupported GPID" indication. In the case of PSC and when penultimate hop popping (PHP) is requested, the penultimate hop also examines the (stored) G- PID during the processing of the MAPPING message. In this case if the G-PID is not supported, then the penultimate hop MUST generate a NOTIFICATION message with a "Routing problem/Unacceptable label - value" indication. + value" indication. The generated NOTIFICATION message MAY include an + Acceptable Label Set, see Section 4. When an error message is not generated, normal processing occurs. In the transit case this will typically result in a REQUEST message being propagated. In the egress case and PHP special case this will typically result in a MAPPING message being generated. -2.1.3. Bandwidth Encoding +2.1.2. Bandwidth Encoding Bandwidth encodings are carried in the CR-LDP Traffic Parameters TLV. See [GMPLS-SIG] for a definition of values to be used for specific signal types. These values are set in the Peak and Committed Data Rate fields of the Traffic Parameters TLV. Other bandwidth/service related parameters in the TLV are ignored and carried transparently. 2.2. Generalized Label The format of a Generalized Label is: @@ -199,35 +183,37 @@ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| 0x0902 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ See [GMPLS-SIG] for a description of parameters and encoding of - SDH, SONET, port, wavelength and other labels. + labels. 2.2.1. Procedures The Generalized Label travels in the upstream direction in MAPPING messages. The presence of both a generalized and normal label TLV in a MAPPING message is a protocol error and should treated as a malformed message by the recipient. The recipient of a MAPPING message containing a Generalized Label verifies that the values passed are acceptable. If the label is unacceptable then the recipient MUST generate a NOTIFICATION message with a "Routing problem/MPLS label allocation failure" indication. + The generated NOTIFICATION message MAY include an Acceptable Label + Set, see Section 4. 2.3. Waveband Switching Waveband switching uses the same format as the generalized label, see section 2.2. The type (0x0903) is assigned for the Waveband Label. In the context of waveband switching, the generalized label has the following format: 0 1 2 3 @@ -309,106 +295,133 @@ Action zero (0) and one (1) TLVs respectively. Ranges of labels/subchannels can be added to or excluded from a Label Set via Action two (2) and three (3) TLVs respectively. When the Label_Set TLVs only list labels/subchannels to exclude, this implies that all other labels are acceptable. The absence of any Label_Set TLVs implies that all labels are acceptable. A Label Set is included when a node wishes to restrict the label(s) that may be used downstream. - On reception of a REQUEST message a CI-capable interface will - restrict its choice of labels to one which is in the Label Set. The - CI-capable receiver may also remove the Label Set prior to forwarding - the REQUEST message. If the node is unable to pick a label from the - Label Set or if there is a problem parsing the Label_Set TLVs, then - the request is terminated and a NOTIFICATION message with a "Routing - problem/Label Set" indication MUST be generated. It is a local matter - if the Label Set is stored for later selection on the MAPPING or if - the selection is made immediately for propagation in the MAPPING. + On reception of a REQUEST message, the receiving node will restrict + its choice of labels to one which is in the Label Set. Nodes capable + of performing label conversion may also remove the Label Set prior to + forwarding the REQUEST message. If the node is unable to pick a + label from the Label Set or if there is a problem parsing the + Label_Set TLVs, then the request is terminated and a NOTIFICATION + message with a "Routing problem/Label Set" indication MUST be + generated. It is a local matter if the Label Set is stored for later + selection on the MAPPING or if the selection is made immediately for + propagation in the MAPPING. - On reception of a REQUEST message for a CI-incapable interface, the - Label Set represented in the message is compared against the set of - available labels at the downstream interface and the resulting - intersecting Label Set is forwarded in a REQUEST message. When the - resulting Label Set is empty, the REQUEST must be terminated, and a - NOTIFICATION message, and a "Routing problem/Label Set" indication - MUST be generated. Note that intersection is based on the physical - labels (actual wavelength/band values) which may have different - logical values on different links, as a result it is the - responsibility of the node to map these values so that they have a - consistent physical meaning, or to drop the particular values from - the set if no suitable logical label value exists. + On reception of a REQUEST message, the Label Set represented in the + message is compared against the set of available labels at the + downstream interface and the resulting intersecting Label Set is + forwarded in a REQUEST message. When the resulting Label Set is + empty, the REQUEST must be terminated, and a NOTIFICATION message, + and a "Routing problem/Label Set" indication MUST be generated. Note + that intersection is based on the physical labels (actual + wavelength/band values) which may have different logical values on + different links, as a result it is the responsibility of the node to + map these values so that they have a consistent physical meaning, or + to drop the particular values from the set if no suitable logical + label value exists. When processing a MAPPING message at an intermediate node, the label propagated upstream MUST fall within the Label Set. - Note, on reception of a MAPPING message for an interface which is CI- - incapable it has no other choice than to use the same physical label - (wavelength/band) as received in the MAPPING. In this case, the use - and propagation of a Label Set will significantly reduce the chances - that this allocation will fail when CI-incapable nodes are traversed. + Note, on reception of a MAPPING message a node that is incapable of + performing label conversion has no other choice than to use the same + physical label (wavelength/band) as received in the MAPPING message. + In this case, the use and propagation of a Label Set will + significantly reduce the chances that this allocation will fail. 3. Bidirectional LSPs Bidirectional LSP setup is indicated by the presence of an Upstream Label in the REQUEST message. An Upstream Label has the same format as the generalized label, see Section 2.2. Upstream Label uses type=0x0906 3.1. Procedures The process of establishing a bidirectional LSP follows the establishment of a unidirectional LSP with some additions. To support bidirectional LSPs an Upstream Label is added to the REQUEST message. The Upstream Label MUST indicate a label that is valid for forwarding at the time the REQUEST message is sent. When a REQUEST message containing an Upstream Label is received, the receiver first verifies that the upstream label is acceptable. If the label is not acceptable, the receiver MUST issue a NOTIFICATION message with a "Routing problem/Unacceptable label value" indication. + The generated NOTIFICATION message MAY include an Acceptable Label + Set, see Section 4. An intermediate node must also allocate a label on the outgoing interface and establish internal data paths before filling in an outgoing Upstream Label and propagating the REQUEST message. If an intermediate node is unable to allocate a label or internal resources, then it MUST issue a NOTIFICATION message with a "Routing problem/Label allocation failure" indication. Terminator nodes process REQUEST messages as usual, with the exception that the upstream label can immediately be used to transport data traffic associated with the LSP upstream towards the initiator. When a bidirectional LSP is removed, both upstream and downstream labels are invalidated and it is no longer valid to send data using the associated labels. -4. Explicit Label Control +4. Notification on Label Error + + This section defines the Acceptable_Label_Set TLV to support + Notification on Label Error per [GMPLS-SIG]. An Acceptable_Label_Set + TLV uses a type value of 0x0907. The remaining contents of the TLV + have the identical format as the Label_Set TLV, see Section 2.5. + + Acceptable_Label_Set TLVs may be carried in NOTIFICATION messages. + The procedures for defining an Acceptable Label Set follow the + procedures for defining a Label Set, see Section 2.5.1. + Specifically, an Acceptable Label Set is defined via one or more + Acceptable_Label_Set TLVs. Specific labels/subchannels can be added + to or excluded from an Acceptable Label Set via Action zero (0) and + one (1) TLVs respectively. Ranges of labels/subchannels can be added + to or excluded from an Acceptable Label Set via Action two (2) and + three (3) TLVs respectively. When the Acceptable_Label_Set TLVs only + list labels/subchannels to exclude, this implies that all other + labels are acceptable. + + The inclusion of Acceptable_Label_Set TLVs is optional. If included, + the NOTIFICATION message SHOULD contain a "Routing + problem/Unacceptable label value" indication. The absence of + Acceptable_Label_Set TLVs does not have any specific meaning. + +5. Explicit Label Control The Label ER-Hop is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |0|0| 0x901 | Length | + |0|0| 0x0806 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L|U| Reserved | Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label (continued) | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ See [GMPLS-SIG] for a description of L, U and Label parameters. -4.1. Procedures +5.1. Procedures The Label ER-Hop follows a ER-Hop containing the IP address, or the interface identifier [MPLS-UNNUM], associated with the link on which it is to be used. The preceding ER-Hop must be strict. Up to two label ER-Hops may be present, one for the downstream label and one for the upstream label. The following SHOULD result in "Bad EXPLICIT_ROUTE" errors: - If the first label ER-Hop is not preceded by a ER-Hop containing an IP address, or a interface identifier [MPLS-UNNUM], associated with an output link. @@ -438,90 +451,89 @@ Note an implication of the above procedures is that the label ER-Hop should never be the first ER-Hop in a newly received message. If the label ER-Hop is the the first ER-Hop an a received ER, then it SHOULD be treated as a "Bad strict node" error. Procedures by which an LSR at the head-end of an LSP obtains the information needed to construct the Label ER-Hop are outside the scope of this document. -5. Protection TLV +6. Protection TLV - The use of the Protection Object is optional. The object is included - to indicate specific protection attributes of an LSP. + The use of the Protection TLV is optional. The TLV is included to + indicate specific protection attributes of an LSP. - The format of Protection Flags Object is: + The format of Protection Information TLV is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |U|F| TBA | Length | + |U|F| 0x0908 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| Reserved | Link Flags| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ See [GMPLS-SIG] for a description of parameters. -5.1. Procedures +6.1. Procedures Transit nodes processing a REQUEST message containing a Protection - Object MUST verify that the requested protection can be satisfied by - the outgoing interface or tunnel (FA). If it cannot, the node MUST + TLV MUST verify that the requested protection can be satisfied by the + outgoing interface or tunnel (FA). If it cannot, the node MUST generate a NOTIFICATION message, with a "Routing problem/Unsupported Link Protection" indication. -6. Acknowledgments +7. Acknowledgments This draft is the work of numerous authors and consists of a composition of a number of previous drafts in this area. A list of the drafts from which material and ideas were incorporated follows: draft-saha-rsvp-optical-signaling-00.txt draft-lang-mpls-rsvp-oxc-00.txt draft-kompella-mpls-optical-00.txt draft-fan-mpls-lambda-signaling-00.txt Valuable comments and input were received from a number of people, notably Adrian Farrel. -7. Security Considerations +8. Security Considerations This draft introduce no new security considerations to [CR-LDP]. -8. References +9. References [CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP", - draft-ietf-mpls-cr-ldp-04.txt, July, 2000. + draft-ietf-mpls-cr-ldp-05.txt, Feb., 2001. [MPLS-HIERARCHY] Kompella, K., and Rekhter, Y., "LSP Hierarchy with MPLS TE", Internet Draft, - draft-ietf-mpls-lsp-hierarchy-00.txt, July 2000. + draft-ietf-mpls-lsp-hierarchy-02.txt, Feb., 2001. +[MPLS-UNNUM] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links + in CR-LDP", Internet Draft, + draft-ietf-mpls-crldp-unnum-01.txt, February 2001 [GMPLS-RSVP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling - RSVP-TE Extensions", Internet Draft, draft-ietf-mpls-generalized-rsvp-te-01.txt, February 2001. [GMPLS-SIG] Ashwood-Smith, P. et al, "Generalized MPLS - Signaling Functional Description", Internet Draft, draft-ietf-mpls-generalized-signaling-02.txt, February 2001. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119. -[FEEDBACK] P. Ashwood-Smith, B. Jamoussi, D. Fedyk, D. Skalecki, - "Improving Topology Data Base Accuracy With LSP Feedback - via CR-LDP", Internet Draft, draft-ietf-mpls-te-feed-00.txt. - -9. Authors' Addresses +10. Authors' Addresses Peter Ashwood-Smith Nortel Networks Corp. P.O. Box 3511 Station C, Ottawa, ON K1Y 4H7 Canada Phone: +1 613 763 4534 Email: petera@nortelnetworks.com Ayan Banerjee @@ -607,20 +619,21 @@ Phone: +1 408 895 5030 Fax: +1 408 895 5050 Email: vsharma@jasminenetworks.com George Swallow Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824 Voice: +1 978 244 8143 Email: swallow@cisco.com + Z. Bo Tang Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Phone: +1 732 923 4231 Fax: +1 732 923 9804 Email: btang@tellium.com -Generated on: Fri Mar 2 14:09:47 EST 2001 +Generated on: Mon Apr 16 19:49:24 EDT 2001