doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc5918.txt b/doc/rfc/rfc5918.txt
new file mode 100644
index 0000000..09d0319
--- /dev/null
+++ b/doc/rfc/rfc5918.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          R. Asati
+Request for Comments: 5918                                 Cisco Systems
+Category: Standards Track                                       I. Minei
+ISSN: 2070-1721                                         Juniper Networks
+                                                               B. Thomas
+                                                             August 2010
+
+
+           Label 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 in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc5918.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Asati, et al.                Standards Track                    [Page 1]
+
+RFC 5918                LDP 'Typed Wildcard' FEC             August 2010
+
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 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 Contents
+
+   1. Introduction ....................................................3
+   2. Specification Language ..........................................4
+   3. The Typed Wildcard FEC Element ..................................4
+   4. Procedures for the Typed Wildcard FEC Element ...................5
+   5. Typed Wildcard FEC Capability ...................................6
+   6. Typed Wildcard FEC Element for Prefix FEC Element ...............7
+   7. Typed Wildcard FEC Element for Host and Wildcard FEC Elements ...8
+   8. IANA Considerations .............................................8
+   9. Security Considerations .........................................8
+   10. Acknowledgments ................................................9
+   11. References .....................................................9
+      11.1. Normative References ......................................9
+      11.2. Informative References ....................................9
+
+
+
+
+
+
+
+
+
+Asati, et al.                Standards Track                    [Page 2]
+
+RFC 5918                LDP 'Typed Wildcard' FEC             August 2010
+
+
+1.  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 by RFC 5036, the Wildcard FEC Element refers to all FECs
+   relative to an optional constraint.  The only constraint RFC 5036
+   specifies is one that limits the scope of the Wildcard FEC Element to
+   "all FECs bound to a given label".
+
+   The RFC 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 by RFC 5036.
+
+   Note that this document does not change procedures specified for the
+   LDP Wildcard FEC Element by RFC 5036.
+
+
+
+
+
+
+Asati, et al.                Standards Track                    [Page 3]
+
+RFC 5918                LDP 'Typed Wildcard' FEC             August 2010
+
+
+2.  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 Router
+
+3.  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 see Section 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 in RFC 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' in Section 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 in RFC
+   5036.  Quoting from RFC 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 per Section 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 Element
+
+   RFC 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, per RFC 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 on http://www.iana.org.
+
+
+
+Asati, et al.                Standards Track                    [Page 7]
+
+RFC 5918                LDP 'Typed Wildcard' FEC             August 2010
+
+
+   The procedures described in Section 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 by RFC 5036.  The [RFC3036] Host FEC Element has been
+   removed from RFC 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 2010
+
+
+10.  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.  References
+
+11.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 2010
+
+
+Authors' 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.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Asati, et al.                Standards Track                   [Page 10]
+