--- 1/draft-ietf-mpls-generalized-cr-ldp-00.txt 2006-02-05 00:38:55.000000000 +0100 +++ 2/draft-ietf-mpls-generalized-cr-ldp-01.txt 2006-02-05 00:38:55.000000000 +0100 @@ -1,50 +1,48 @@ Network Working Group Peter Ashwood-Smith (Nortel Networks Corp.) Internet Draft Ayan Banerjee (Calient Networks) -Expiration Date: May 2001 Lou Berger (Movaz Networks) +Expiration Date: September 2001 Lou Berger (Movaz Networks) Greg Bernstein (Ciena Corporation) John Drake (Calient Networks) Yanhe Fan (Axiowave Networks) Kireeti Kompella (Juniper Networks, Inc.) - Eric Mannie (GTS) + Eric Mannie (EBONE) Jonathan P. Lang (Calient Networks) Bala Rajagopalan (Tellium, Inc.) - Yakov Rekhter (Cisco Systems) + Yakov Rekhter (Juniper Networks, Inc.) Debanjan Saha (Tellium, Inc.) - Vishal Sharma (Tellabs) + Vishal Sharma (Jasmine Networks) George Swallow (Cisco Systems) Z. Bo Tang (Tellium, Inc.) - November 2000 + March 2001 Generalized MPLS Signaling - CR-LDP Extensions - draft-ietf-mpls-generalized-cr-ldp-00.txt + draft-ietf-mpls-generalized-cr-ldp-01.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." - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. + 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. 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]. @@ -61,30 +59,31 @@ 2.2.1 Procedures ................................................ 6 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 Acknowledgments ........................................... 12 - 6 Security Considerations ................................... 12 - 7 References ................................................ 12 - 8 Authors' Addresses ........................................ 13 + 5 Protection TLV ............................................ 12 + 5.1 Procedures ................................................ 12 + 6 Acknowledgments ........................................... 12 + 7 Security Considerations ................................... 13 + 8 References ................................................ 13 + 9 Authors' Addresses ........................................ 13 Changes from previous version: -o Moved protocol specific details into two documents, one for RSVP-TE - and one for CR-LDP. -o Clarified Label Set +o Revised label request +o Moved protection flags to separate object o Minor text cleanup 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 @@ -120,68 +119,63 @@ LSRs. A Generalized Label Request TLV is set by the ingress node, transparently passed by transit nodes, and used by the egress node. The format of a Generalized Label Request 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| 0x0901 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | LSP Enc. Type |Link Prot.Flags| G-PID | + | 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 |Link Prot.Flags| G-PID | + | LSP Enc. Type | Reserved | G-PID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | RGT | RT | Reserved | RNC | + | RNC | Signal Type |Rsrved.| RGT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ See [GMPLS-SIG] for a description of parameters. 2.1.2. Procedures - A node processing the REQUEST message containing the 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. + 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 dynamically established or may be solely administratively controlled. For more information on tunnels and processing of ER hops when using tunnels see [MPLS-HIERARCHY]. Transit and egress nodes MUST verify that the node itself and, where appropriate, that the outgoing interface or tunnel can support the requested LSP Encoding Type. If encoding cannot be supported, the node MUST generate a NOTIFICATION message, with a "Routing problem/Unsupported Encoding" indication. - Transit nodes MUST verify that the outgoing interface or tunnel can - support the requested Link Protection Flags. If it cannot, the node - MUST generate a NOTIFICATION message, with a "Routing - problem/Unsupported Link Protection" 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. @@ -400,24 +394,20 @@ |0|0| 0x901 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L|U| Reserved | Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label (continued) | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ See [GMPLS-SIG] for a description of L, U and Label parameters. - Length - - Specifies the length of the value field in bytes. - 4.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 @@ -448,65 +438,90 @@ 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. Acknowledgments +5. Protection TLV + + The use of the Protection Object is optional. The object is included + to indicate specific protection attributes of an LSP. + + The format of Protection Flags Object 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |S| Reserved | Link Flags| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + See [GMPLS-SIG] for a description of parameters. + +5.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 + generate a NOTIFICATION message, with a "Routing problem/Unsupported + Link Protection" indication. + +6. 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. -6. Security Considerations +7. Security Considerations This draft introduce no new security considerations to [CR-LDP]. -7. References +8. References [CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP", draft-ietf-mpls-cr-ldp-04.txt, July, 2000. [MPLS-HIERARCHY] Kompella, K., and Rekhter, Y., "LSP Hierarchy with MPLS TE", Internet Draft, draft-ietf-mpls-lsp-hierarchy-00.txt, July 2000. [GMPLS-RSVP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling - RSVP-TE Extensions", Internet Draft, - draft-ietf-mpls-generalized-rsvp-te-00.txt, - November 2000. + 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-01.txt, - November 2000. + 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. -8. Authors' Addresses +9. 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 @@ -508,24 +523,26 @@ Canada Phone: +1 613 763 4534 Email: petera@nortelnetworks.com Ayan Banerjee Calient Networks 5853 Rue Ferrari San Jose, CA 95138 Phone: +1 408 972-3645 Email: abanerjee@calient.net - Lou Berger - Movaz Networks - Phone: +1 301 468 9228 + Movaz Networks, Inc. + 7926 Jones Branch Drive + Suite 615 + McLean VA, 22102 + Phone: +1 703 847-1801 Email: lberger@movaz.com Greg Bernstein Ciena Corporation 10480 Ridgeview Court Cupertino, CA 94014 Phone: +1 408 366 4713 Email: greg@ciena.com John Drake @@ -545,63 +563,64 @@ Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94089 Email: kireeti@juniper.net Jonathan P. Lang Calient Networks 25 Castilian Goleta, CA 93117 Email: jplang@calient.net - Eric Mannie - GTS + EBONE Terhulpsesteenweg 6A 1560 Hoeilaart - Belgium Phone: +32 2 658 56 52 Mobile: +32 496 58 56 52 Fax: +32 2 658 51 18 - Email: eric.mannie@gts.com + Email: eric.mannie@ebone.com Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Phone: +1 732 923 4237 Fax: +1 732 923 9804 Email: braja@tellium.com Yakov Rekhter - cisco Systems - Email: yakov@cisco.com + Juniper Networks, Inc. + Email: yakov@juniper.net Debanjan Saha Tellium Optical Systems 2 Crescent Place Oceanport, NJ 07757-0901 Phone: +1 732 923 4264 Fax: +1 732 923 9804 Email: dsaha@tellium.com + Vishal Sharma - Tellabs Research Center - One Kendall Square - Bldg. 100, Ste. 121 - Cambridge, MA 02139-1562 - Phone: +1 617 577 8760 - Email: Vishal.Sharma@tellabs.com + Jasmine Networks, Inc. + 3061 Zanker Road, Suite B + San Jose, CA 95134 + 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