doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

diff --git a/doc/rfc/rfc8596.txt b/doc/rfc/rfc8596.txt
new file mode 100644
index 0000000..8e44010
--- /dev/null
+++ b/doc/rfc/rfc8596.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          A. Malis
+Request for Comments: 8596                                     S. Bryant
+Category: Informational                                        Futurewei
+ISSN: 2070-1721                                               J. Halpern
+                                                                Ericsson
+                                                           W. Henderickx
+                                                                   Nokia
+                                                               June 2019
+
+
+  MPLS Transport Encapsulation for the Service Function Chaining (SFC)
+                      Network Service Header (NSH)
+
+Abstract
+
+   This document describes how to use a Service Function Forwarder (SFF)
+   Label (similar to a pseudowire label or VPN label) to indicate the
+   presence of a Service Function Chaining (SFC) Network Service Header
+   (NSH) between an MPLS label stack and the NSH original packet/frame.
+   This allows SFC packets using the NSH to be forwarded between SFFs
+   over an MPLS network.  The label is also used to select between
+   multiple SFFs in the destination MPLS node.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   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).  Not all documents
+   approved by the IESG are candidates for any level of Internet
+   Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8596.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Malis, et al.                 Informational                     [Page 1]
+
+RFC 8596                  MPLS for the SFC NSH                 June 2019
+
+
+Copyright Notice
+
+   Copyright (c) 2019 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
+   (https://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.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Terminology ................................................3
+   2. MPLS Encapsulation Using an SFF Label ...........................3
+      2.1. MPLS Label Stack Construction at the Sending Node ..........4
+      2.2. SFF Label Processing at the Destination Node ...............5
+   3. Equal-Cost Multipath (ECMP) Considerations ......................5
+   4. Operations, Administration, and Maintenance (OAM)
+      Considerations ..................................................6
+   5. IANA Considerations .............................................6
+   6. Security Considerations .........................................6
+   7. References ......................................................7
+      7.1. Normative References .......................................7
+      7.2. Informative References .....................................8
+   Acknowledgements ...................................................9
+   Authors' Addresses .................................................9
+
+1.  Introduction
+
+   As discussed in [RFC8300], a number of transport encapsulations for
+   the Service Function Chaining (SFC) Network Service Header (NSH)
+   already exist, such as Ethernet, UDP, GRE, and others.
+
+   This document describes an MPLS transport encapsulation for the NSH
+   and how to use a Service Function Forwarder (SFF) [RFC7665] Label to
+   indicate the presence of the NSH in the MPLS packet payload.  This
+   allows SFC packets using the NSH to be forwarded between SFFs in an
+   MPLS transport network, where MPLS is used to interconnect the
+   network nodes that contain one or more SFFs.  The label is also used
+   to select between multiple SFFs in the destination MPLS node.
+
+
+
+
+
+Malis, et al.                 Informational                     [Page 2]
+
+RFC 8596                  MPLS for the SFC NSH                 June 2019
+
+
+   From an SFC perspective, this encapsulation is equivalent to other
+   transport encapsulations of packets using the NSH.  This can be
+   illustrated by adding an additional line to the example of a next-hop
+   SPI / SI-to-network ("SPI" and "SI" stand for "Service Path
+   Identifier" and "Service Index") overlay network locator mapping in
+   Table 1 of [RFC8300]:
+
+     +------+------+---------------------+-------------------------+
+     | SPI  | SI   | Next Hop(s)         | Transport Encapsulation |
+     +------+------+---------------------+-------------------------+
+     | 25   | 220  | Label 5467          | MPLS                    |
+     +------+------+---------------------+-------------------------+
+
+                 Table 1: Extension to Table 1 in RFC 8300
+
+   SFF Labels are similar to other service labels at the bottom of an
+   MPLS label stack that denote the contents of the MPLS payload being
+   other than a normally routed IP packet, such as a Layer 2 pseudowire,
+   an IP packet that is routed in a VPN context with a private address,
+   or an Ethernet virtual private wire service.
+
+   This informational document follows well-established MPLS procedures
+   and does not require any actions by IANA or any new protocol
+   extensions.
+
+   Note that using the MPLS label stack as a replacement for the SFC
+   NSH, covering use cases that do not require per-packet metadata, is
+   described in [RFC8595].
+
+1.1.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+2.  MPLS Encapsulation Using an SFF Label
+
+   The encapsulation is a standard MPLS label stack [RFC3032] with an
+   SFF Label at the bottom of the stack, followed by an NSH as defined
+   by [RFC8300] and the NSH original packet/frame.
+
+   Much like a pseudowire label, an SFF Label MUST be allocated by the
+   downstream receiver of the NSH from its per-platform label space,
+   since the meaning of the label is identical, independent of which
+   incoming interface it is received from [RFC3031].
+
+
+
+
+Malis, et al.                 Informational                     [Page 3]
+
+RFC 8596                  MPLS for the SFC NSH                 June 2019
+
+
+   If a receiving node supports more than one SFF (i.e., more than one
+   SFC forwarding instance), then the SFF Label can be used to select
+   the proper SFF, by having the receiving node advertise more than one
+   SFF Label to its upstream sending nodes as appropriate.
+
+   The method used by the downstream receiving node to advertise SFF
+   Labels to the upstream sending node is out of scope for this
+   document.  That said, a number of methods are possible, such as via a
+   protocol exchange, or via a controller that manages both the sender
+   and the receiver using the Network Configuration Protocol
+   (NETCONF) / YANG, BGP, the Path Computation Element Communication
+   Protocol (PCEP), etc.  One such BGP-based method has already been
+   defined and is documented in [BGP-NSH-SFC].  This does not constrain
+   the further definition of other such advertisement methods in the
+   future.
+
+   While the SFF Label will usually be at the bottom of the label stack,
+   there may be cases where there are additional label stack entries
+   beneath it.  For example, when an Associated Channel Header (ACH) is
+   carried that applies to the SFF, a Generic Associated Channel Label
+   (GAL) [RFC5586] will be in the label stack below the SFF.  Similarly,
+   an Entropy Label Indicator / Entropy Label (ELI/EL) [RFC6790] may be
+   carried below the SFF in the label stack.  This is identical to the
+   situation with VPN labels.
+
+   This document does not define the setting of the Traffic Class (TC)
+   field [RFC5462] (formerly known as the Experimental Use (EXP) bits
+   [RFC3032]) in the SFF Label.
+
+2.1.  MPLS Label Stack Construction at the Sending Node
+
+   When one SFF wishes to send an SFC packet with an NSH to another SFF
+   over an MPLS transport network, a label stack needs to be constructed
+   by the MPLS node that contains the sending SFF in order to transport
+   the packet to the destination MPLS node that contains the receiving
+   SFF.  The label stack is constructed as follows:
+
+   1.  Push zero or more labels that are interpreted by the destination
+       MPLS node on to the packet, such as the GAL [RFC5586] (see
+       Section 4).  The TTL for these labels is set according to the
+       relevant standards that define these labels.
+
+   2.  Push the SFF Label to identify the desired SFF in the receiving
+       MPLS node.  The TTL for this MPLS label MUST be set to 1 to avoid
+       mis-forwarding.
+
+
+
+
+
+
+Malis, et al.                 Informational                     [Page 4]
+
+RFC 8596                  MPLS for the SFC NSH                 June 2019
+
+
+   3.  Push zero or more additional labels such that (a) the resulting
+       label stack will cause the packet to be transported to the
+       destination MPLS node, and (b) when the packet arrives at the
+       destination node, either:
+
+       *  the SFF Label will be at the top of the label stack (this is
+          typically the case when penultimate hop popping is used at the
+          penultimate node), or
+
+       *  as a part of normal MPLS processing, the SFF Label becomes the
+          top label in the stack before the packet is forwarded to
+          another node and before the packet is dispatched to a higher
+          layer.
+
+      The TTL for these labels is set by configuration or set to the
+      defaults for normal MPLS operation in the network.
+
+2.2.  SFF Label Processing at the Destination Node
+
+   The destination MPLS node performs a lookup on the SFF Label to
+   retrieve the next-hop context between the SFF and SF, e.g., to
+   retrieve the destination Media Access Control (MAC) address in the
+   case where native Ethernet encapsulation is used between the SFF and
+   SF.  How the next-hop context is populated is out of scope for this
+   document.
+
+   The receiving SFF SHOULD check that the received SFF Label has a TTL
+   of 1 upon receipt.  Any other values indicate a likely error
+   condition and SHOULD result in discarding the packet.
+
+   The receiving MPLS node then pops the SFF Label (and any labels
+   beneath it) so that the destination SFF receives the SFC packet with
+   the NSH at the top of the packet.
+
+3.  Equal-Cost Multipath (ECMP) Considerations
+
+   As discussed in [RFC4928] and [RFC7325], there are ECMP
+   considerations for payloads carried by MPLS.
+
+   Many existing routers use deep packet inspection to examine the
+   payload of an MPLS packet.  If the first nibble of the payload is
+   equal to 0x4 or 0x6, these routers (sometimes incorrectly, as
+   discussed in [RFC4928]) assume that the payload is IPv4 or IPv6,
+   respectively and, as a result, perform ECMP load balancing based on
+   (presumed) information present in IP/TCP/UDP payload headers or in a
+   combination of MPLS label stack and (presumed) IP/TCP/UDP payload
+   headers in the packet.
+
+
+
+
+Malis, et al.                 Informational                     [Page 5]
+
+RFC 8596                  MPLS for the SFC NSH                 June 2019
+
+
+   For SFC, ECMP may or may not be desirable.  To prevent ECMP when it
+   is not desired, the NSH Base Header was carefully constructed so that
+   the NSH could not look like IPv4 or IPv6 based on its first nibble.
+   See Section 2.2 of [RFC8300] for further details.  Accordingly, the
+   default behavior for MPLS-encapsulated SFC is to not use ECMP other
+   than by using entropy derived from the MPLS label stack.  This
+   results in all packets going to the same SF taking the same path
+   regardless of the use of ECMP in the network.
+
+   If ECMP is desired when SFC is used with an MPLS transport network,
+   there are two possible options: entropy labels [RFC6790] and
+   flow-aware transport [RFC6391] labels.  A recommendation regarding
+   choosing between these options, and their proper placement in the
+   label stack, is left for future study.
+
+4.  Operations, Administration, and Maintenance (OAM) Considerations
+
+   OAM at the SFC layer is handled by SFC-defined mechanisms [RFC8300].
+   However, OAM may be required at the MPLS transport layer.  If so,
+   then standard MPLS-layer OAM mechanisms such as the GAL [RFC5586] may
+   be used at the transport label layer.
+
+5.  IANA Considerations
+
+   This document has no IANA actions.
+
+6.  Security Considerations
+
+   This document describes a method for transporting SFC packets using
+   the NSH over an MPLS transport network.  It follows well-established
+   MPLS procedures in widespread operational use.  It does not define
+   any new protocol elements or allocate any new code points, and it is
+   no more or less secure than carrying any other protocol over MPLS.
+   To the MPLS network, the NSH and its contents are simply an opaque
+   payload.
+
+   In addition, the security considerations in [RFC8595] also apply to
+   this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Malis, et al.                 Informational                     [Page 6]
+
+RFC 8596                  MPLS for the SFC NSH                 June 2019
+
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
+              Label Switching Architecture", RFC 3031,
+              DOI 10.17487/RFC3031, January 2001,
+              <https://www.rfc-editor.org/info/rfc3031>.
+
+   [RFC3032]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
+              Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
+              Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
+              <https://www.rfc-editor.org/info/rfc3032>.
+
+   [RFC5462]  Andersson, L. and R. Asati, "Multiprotocol Label Switching
+              (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
+              Class" Field", RFC 5462, DOI 10.17487/RFC5462,
+              February 2009, <https://www.rfc-editor.org/info/rfc5462>.
+
+   [RFC7665]  Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
+              Chaining (SFC) Architecture", RFC 7665,
+              DOI 10.17487/RFC7665, October 2015,
+              <https://www.rfc-editor.org/info/rfc7665>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in
+              RFC 2119 Key Words", BCP 14, RFC 8174,
+              DOI 10.17487/RFC8174, May 2017,
+              <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8300]  Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
+              "Network Service Header (NSH)", RFC 8300,
+              DOI 10.17487/RFC8300, January 2018,
+              <https://www.rfc-editor.org/info/rfc8300>.
+
+   [RFC8595]  Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based
+              Forwarding Plane for Service Function Chaining", RFC 8595,
+              DOI 10.17487/RFC8595, June 2019,
+              <https://www.rfc-editor.org/info/rfc8595>.
+
+
+
+
+
+
+
+
+Malis, et al.                 Informational                     [Page 7]
+
+RFC 8596                  MPLS for the SFC NSH                 June 2019
+
+
+7.2.  Informative References
+
+   [BGP-NSH-SFC]
+              Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L.
+              Jalil, "BGP Control Plane for NSH SFC", Work in Progress,
+              draft-ietf-bess-nsh-bgp-control-plane-11, May 2019.
+
+   [RFC4928]  Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal
+              Cost Multipath Treatment in MPLS Networks", BCP 128,
+              RFC 4928, DOI 10.17487/RFC4928, June 2007,
+              <https://www.rfc-editor.org/info/rfc4928>.
+
+   [RFC5586]  Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
+              "MPLS Generic Associated Channel", RFC 5586,
+              DOI 10.17487/RFC5586, June 2009,
+              <https://www.rfc-editor.org/info/rfc5586>.
+
+   [RFC6391]  Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V.,
+              Regan, J., and S. Amante, "Flow-Aware Transport of
+              Pseudowires over an MPLS Packet Switched Network",
+              RFC 6391, DOI 10.17487/RFC6391, November 2011,
+              <https://www.rfc-editor.org/info/rfc6391>.
+
+   [RFC6790]  Kompella, K., Drake, J., Amante, S., Henderickx, W., and
+              L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
+              RFC 6790, DOI 10.17487/RFC6790, November 2012,
+              <https://www.rfc-editor.org/info/rfc6790>.
+
+   [RFC7325]  Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A.,
+              and C. Pignataro, "MPLS Forwarding Compliance and
+              Performance Requirements", RFC 7325, DOI 10.17487/RFC7325,
+              August 2014, <https://www.rfc-editor.org/info/rfc7325>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Malis, et al.                 Informational                     [Page 8]
+
+RFC 8596                  MPLS for the SFC NSH                 June 2019
+
+
+Acknowledgements
+
+   The authors would like to thank Jim Guichard, Eric Rosen, Med
+   Boucadair, Alexander (Sasha) Vainshtein, Jeff Tantsura, Anoop
+   Ghanwani, John Drake, Loa Andersson, Carlos Pignataro, Christian
+   Hopps, and Benjamin Kaduk for their reviews and comments.
+
+Authors' Addresses
+
+   Andrew G. Malis
+   Futurewei
+
+   Email: agmalis@gmail.com
+
+
+   Stewart Bryant
+   Futurewei
+
+   Email: stewart.bryant@gmail.com
+
+
+   Joel M. Halpern
+   Ericsson
+
+   Email: joel.halpern@ericsson.com
+
+
+   Wim Henderickx
+   Nokia
+
+   Email: wim.henderickx@nokia.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Malis, et al.                 Informational                     [Page 9]
+