Movatterモバイル変換

[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Errata] [Info page]

PROPOSED STANDARD
Updated by:7358Errata Exist

Internet Engineering Task Force (IETF)                          R. AsatiRequest for Comments: 5918                                 Cisco SystemsCategory: Standards Track                                       I. MineiISSN: 2070-1721                                         Juniper Networks                                                               B. Thomas                                                             August 2010Label Distribution Protocol (LDP) 'Typed Wildcard'Forward Equivalence Class (FEC)Abstract   The Label Distribution Protocol (LDP) specification for the Wildcard   Forward Equivalence Class (FEC) element has several limitations.   This document addresses those limitations by defining a Typed   Wildcard FEC Element and associated procedures.  In addition, it   defines a new LDP capability to address backward compatibility.Status of This Memo   This is an Internet Standards Track document.   This document is a product of the Internet Engineering Task Force   (IETF).  It represents the consensus of the IETF community.  It has   received public review and has been approved for publication by the   Internet Engineering Steering Group (IESG).  Further information on   Internet Standards is available inSection 2 of RFC 5741.   Information about the current status of this document, any errata,   and how to provide feedback on it may be obtained athttp://www.rfc-editor.org/info/rfc5918.Asati, et al.                Standards Track                    [Page 1]

RFC 5918 LDP 'Typed Wildcard' FEC August 2010Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject toBCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.Table of Contents1. Introduction ....................................................32. Specification Language ..........................................43. The Typed Wildcard FEC Element ..................................44. Procedures for the Typed Wildcard FEC Element ...................55. Typed Wildcard FEC Capability ...................................66. Typed Wildcard FEC Element for Prefix FEC Element ...............77. Typed Wildcard FEC Element for Host and Wildcard FEC Elements ...88. IANA Considerations .............................................89. Security Considerations .........................................810. Acknowledgments ................................................911. References .....................................................911.1. Normative References ......................................911.2. Informative References ....................................9Asati, et al. Standards Track [Page 2]

RFC 5918 LDP 'Typed Wildcard' FEC August 20101. Introduction LDP [RFC5036] distributes labels for Forwarding Equivalence Classes (FECs). LDP uses FEC TLVs in LDP messages to specify FECs. An LDP FEC TLV includes one or more FEC elements. A FEC element includes a FEC type and an optional type-dependent value.RFC 5036 specifies two FEC types (Prefix and Wildcard), and other documents specify additional FEC types; e.g., see [RFC4447] and [MLDP]. As specified byRFC 5036, the Wildcard FEC Element refers to all FECs relative to an optional constraint. The only constraintRFC 5036 specifies is one that limits the scope of the Wildcard FEC Element to "all FECs bound to a given label". TheRFC 5036 specification of the Wildcard FEC Element has the following deficiencies that limit its utility: 1) The Wildcard FEC Element is untyped. There are situations where it would be useful to be able to refer to all FECs of a given type (as another constraint). 2) Use of the Wildcard FEC Element is limited to Label Withdraw and Label Release messages only. There are situations where it would be useful to have a Wildcard FEC Element, with type constraint, in Label Request messages. This document: - addresses the above limitations by defining a Typed Wildcard FEC Element and procedures for its use. - specifies use of the LDP capability mechanism [RFC5561] at session establishment time for informing a peer that an LDP speaker is capable of handling the Typed Wildcard FEC. - specifies use of the Typed Wildcard FEC Element in a Label Request message. - specifies the Typed Wildcard FEC Element for the Prefix FEC Element specified byRFC 5036. Note that this document does not change procedures specified for the LDP Wildcard FEC Element byRFC 5036.Asati, et al. Standards Track [Page 3]

RFC 5918                LDP 'Typed Wildcard' FEC             August 20102.  Specification Language   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].   LDP   - Label Distribution Protocol   FEC   - Forwarding Equivalence Class   TLV   - Type Length Value   LSR   - Label Switching Router3.  The Typed Wildcard FEC Element   The Typed Wildcard FEC Element refers to all FECs of the specified   type that meet the constraint.  It specifies a 'FEC Element Type' and   an optional constraint, which is intended to provide additional   information.   The format of the Typed Wildcard FEC Element 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 2      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      | Typed (0x05)  | FEC Element   | Len FEC Type  |               |      | Wildcard      | Type          | Info          |               |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |      |                                                               |      ~          Additional FEC Type-specific Information             ~      |                  (Optional)                                   |      |                                               +-+-+-+-+-+-+-+-+      |                                               |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                       Figure 1: Typed Wildcard FEC Element   Where:      Typed Wildcard: One-octet FEC Element Type (0x05).      FEC Element Type: One-octet FEC Element Type that specifies the         FEC Element Type to be wildcarded.  Please seeSection 3.4.1 of         RFC 5036.Asati, et al.                Standards Track                    [Page 4]

RFC 5918 LDP 'Typed Wildcard' FEC August 2010 Any (future) document specifying a new FEC Element Type (not defined inRFC 5036) should prescribe whether typed wildcarding is needed for that FEC Element Type. Len FEC Type Info: One octet that specifies the length in octets of the FEC Type Specific information field. It MUST be set to 0 if there is no Additional FEC Type-specific Information. Additional FEC Type-specific Information (Optional): Additional information that is specific to the FEC Element Type and that is required to fully specify the Typed Wildcard. If this field is absent, then all FECs of the specified FEC Type would be matched. Any (future) document specifying Typed wildcarding for any FEC Element Type should also specify the length and format of Additional FEC Type Specific Information, if included. This document specifies one FEC Element Type instance (e.g., Prefix FEC) for the 'Typed Wildcard FEC Element' inSection 6.4. Procedures for the Typed Wildcard FEC Element When a FEC TLV contains a Typed Wildcard FEC Element, the Typed Wildcard FEC Element MUST be the only FEC Element in the TLV. If an LDP speaker receives a FEC TLV containing a Typed Wildcard FEC Element and any other FEC elements, then the LDP speaker should ignore the other FEC elements and continue processing as if the message only contains the Typed Wildcard FEC Element. An LDP implementation that supports the Typed Wildcard FEC Element MUST support its use in Label Request, Label Withdraw, and Label Release messages. An LDP implementation that supports the Typed Wildcard FEC Element MUST support it for every FEC Element Type defined in [RFC5036]. Receipt of a Label Request message with a FEC TLV containing a Typed Wildcard FEC Element is interpreted as a request to send one or more Label Mappings for all FECs of the type specified by the FEC Element Type field in the Typed Wildcard FEC Element encoding. An LDP implementation that supports the Typed Wildcard FEC Element MUST support the following constraints whenever a Typed Wildcard FEC appears in a Label Withdraw or Label Release message:Asati, et al. Standards Track [Page 5]

RFC 5918                LDP 'Typed Wildcard' FEC             August 2010   1) If the message carries an optional Label TLV, the Typed Wildcard      FEC Element refers to all FECs of the specified FEC type bound to      the specified label.   2) If the message has no Label TLV, the Typed Wildcard FEC Element      refers to all FECs of the specified FEC type.   Backwards compatibility with a router not supporting the Typed   Wildcard FEC element is ensured by the FEC procedures defined inRFC5036.  Quoting fromRFC 5036:      If it [an LSR] encounters a FEC Element type it cannot decode, it      SHOULD stop decoding the FEC TLV, abort processing the message      containing the TLV, and send an "Unknown FEC" Notification message      to its LDP peer signaling an error.   A router receiving a FEC TLV containing a Typed Wildcard FEC element   for either a FEC Element Type that it doesn't support or for a FEC   Element Type that doesn't support the use of wildcarding, MUST stop   decoding the FEC TLV, abort processing the message containing the   TLV, and send an "Unknown FEC" Notification message to its LDP peer   to signal an error.   A router receiving a FEC TLV containing a Typed Wildcard FEC element   MAY also leverage mechanisms defined in [RFC5919] (say, if it had   zero label binding for the requested FEC type, etc.).5.  Typed Wildcard FEC Capability   As noted above,RFC 5036 FEC procedures provide for backward   compatibility with an LSR not supporting the Typed Wildcard FEC   Element.  However, they don't provide means for an LSR that wishes to   use the Typed Wildcard FEC Element to determine whether a peer   supports it other than to send a message that uses the FEC Element   and to wait and see how the peer responds.   An LDP speaker that supports the Typed Wildcard FEC Element MUST   inform its peers of the support by including a Typed Wildcard FEC   Element Capability Parameter [RFC5561] in its Initialization messages   only.   The Capability Parameter for the Typed Wildcard FEC capability is a   TLV with the following format:Asati, et al.                Standards Track                    [Page 6]

RFC 5918                LDP 'Typed Wildcard' FEC             August 2010      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|Typed WCard FEC Cap(0x050B)|            Length             |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      |S| Reserved    |      +-+-+-+-+-+-+-+-+                  Figure 2: Typed Wildcard FEC Capability Format   Where:      U and F bits: MUST be 1 and 0, respectively, as perSection 3 of         LDP Capabilities [RFC5561].      Typed WCard FEC Cap: 0x050B      Length: Two octets.  It MUST be set to 0x0001.      S-bit: MUST be 1 (indicates that capability is being advertised).6.  Typed Wildcard FEC Element for Prefix FEC ElementRFC 5036 defines the Prefix FEC Element, but it does not specify a   Typed Wildcard for it.  This section specifies the Typed Wildcard FEC   Element for Prefix FEC Elements.   The format of the Prefix FEC Typed Wildcard FEC Element ("Prefix FEC   Wildcard" for short), based on Figure 1, 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 2      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      | Typed Wcard   | Type = Prefix |   Len = 2     |  Address...   |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      | ...Family     |      +-+-+-+-+-+-+-+-+           Figure 3: Format of Prefix FEC Element Using Typed Wildcard   Where:      FEC Element Type: "Prefix" FEC Element (0x02, perRFC 5036).      Len FEC Type Info: Two octets.  It MUST be set to 0x0002.      Address Family: Two-octet quantity containing a value from the         "ADDRESS FAMILY NUMBERS" registry onhttp://www.iana.org.Asati, et al.                Standards Track                    [Page 7]

RFC 5918 LDP 'Typed Wildcard' FEC August 2010 The procedures described inSection 4 apply to the Prefix FEC Wildcard processing.7. Typed Wildcard FEC Element for Host and Wildcard FEC Elements There is no need to specify Typed Wildcard FEC Elements for the Host FEC Element specified by [RFC3036], nor for the Wildcard FEC Element specified byRFC 5036. The [RFC3036] Host FEC Element has been removed fromRFC 5036, and the Wildcard FEC Element is untyped by definition. In other words, the 'FEC Element Type' field in 'Typed Wildcard FEC Element' MUST NOT be either 0x01 or 0x03.8. IANA Considerations This document introduces a new LDP FEC Element Type and a new LDP Capability, both of which have been assigned by IANA. IANA has assigned a 'Typed Wildcard FEC Element' code point (0x05) from the LDP FEC Type Name Space. [RFC5036] partitions the FEC Type Name Space into 3 regions: IETF Consensus region, First Come First Served region, and Private Use region. The code point 0x05 is from the IETF Consensus range. IANA has assigned a 'Typed Wildcard FEC Capability' code point (0x050B) from the TLV Type name space. [RFC5036] partitions the TLV TYPE name space into 3 regions: IETF Consensus region, Vendor Private Use region, and Experimental Use region. The code point 0x050B is from the IETF Consensus range.9. Security Considerations No security considerations beyond those that apply to the base LDP specification [RFC5036] and that are further described in [RFC5920] apply to use of the Typed Wildcard FEC Elements as described in this document. One could deduce that the security exposure is reduced by this document, since an LDP speaker using the Typed Wildcard FEC Element could use a single message to request, withdraw, or release all the label mappings of a particular type (a particular Address Family Identifier (AFI), for example), whereas an LDP speaker using the Wildcard FEC Element, as defined in the base LDP specification [RFC5036], could use a single message to request, withdraw, or release all the label mappings of all types (all AFIs, for example).Asati, et al. Standards Track [Page 8]

RFC 5918                LDP 'Typed Wildcard' FEC             August 201010.  Acknowledgments   The authors would like to thank Yakov Rekhter for suggesting that the   limitations of the Wildcard FEC be addressed.  Also, thanks to Adrian   Farrel, Kamran Raza, and Richard L. Barnes for extensive review of   this document.11.  References11.1.  Normative References   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate              Requirement Levels",BCP 14,RFC 2119, March 1997.   [RFC5036]  Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,              "LDP Specification",RFC 5036, October 2007.   [RFC5561]  Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.              Le Roux, "LDP Capabilities",RFC 5561, July 2009.11.2.  Informative References   [RFC3036]  Andersson, L., Doolan, P., Feldman, N., Fredette, A., and              B. Thomas, "LDP Specification",RFC 3036, January 2001.   [RFC4447]  Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and              G. Heron, "Pseudowire Setup and Maintenance Using the              Label Distribution Protocol (LDP)",RFC 4447, April 2006.   [RFC5919]  Asati, R., Mohapatra, P., Minei, I., and B. Thomas,              "Signaling LDP Label Advertisement Completion",RFC 5919,              August 2010.   [RFC5920]  Fang, L., Ed., "Security Framework for MPLS and GMPLS              Networks",RFC 5920, July 2010.   [MLDP]     Minei, I., Ed., Kompella, K., Wijnands, I., Ed., and B.              Thomas, "Label Distribution Protocol Extensions for Point-              to-Multipoint and Multipoint-to-Multipoint Label Switched              Paths", Work in Progress, July 2010.Asati, et al.                Standards Track                    [Page 9]

RFC 5918                LDP 'Typed Wildcard' FEC             August 2010Authors' Addresses   Rajiv Asati   Cisco Systems   7025-6 Kit Creek Rd.   Research Triangle Park, NC  27709-4987   EMail: rajiva@cisco.com   Ina Minei   Juniper Networks   1194 North Mathilda Ave.   Sunnyvale, CA  94089   EMail: ina@juniper.net   Bob Thomas   EMail: bobthomas@alum.mit.eduAsati, et al.                Standards Track                   [Page 10]

[8]ページ先頭