doc: Add RFC documents

1 files changed, 3363 insertions, 0 deletions

diff --git a/doc/rfc/rfc7325.txt b/doc/rfc/rfc7325.txt
new file mode 100644
index 0000000..e6f1bf6
--- /dev/null
+++ b/doc/rfc/rfc7325.txt
@@ -0,0 +1,3363 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                C. Villamizar, Ed.
+Request for Comments: 7325                                         OCCNC
+Category: Informational                                      K. Kompella
+ISSN: 2070-1721                                         Juniper Networks
+                                                               S. Amante
+                                                              Apple Inc.
+                                                                A. Malis
+                                                                  Huawei
+                                                            C. Pignataro
+                                                                   Cisco
+                                                             August 2014
+
+
+        MPLS Forwarding Compliance and Performance Requirements
+
+Abstract
+
+   This document provides guidelines for implementers regarding MPLS
+   forwarding and a basis for evaluations of forwarding implementations.
+   Guidelines cover many aspects of MPLS forwarding.  Topics are
+   highlighted where implementers might otherwise overlook practical
+   requirements that are unstated or underemphasized, or that are
+   optional for conformance to RFCs but often considered mandatory by
+   providers.
+
+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 a candidate for any level of Internet
+   Standard; see 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/rfc7325.
+
+
+
+
+
+
+
+
+
+
+
+Villamizar, et al.            Informational                     [Page 1]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+Copyright Notice
+
+   Copyright (c) 2014 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.
+
+Table of Contents
+
+   1.  Introduction and Document Scope . . . . . . . . . . . . . . .   4
+     1.1.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .   4
+     1.2.  Use of Requirements Language  . . . . . . . . . . . . . .   8
+     1.3.  Apparent Misconceptions . . . . . . . . . . . . . . . . .   9
+     1.4.  Target Audience . . . . . . . . . . . . . . . . . . . . .  10
+   2.  Forwarding Issues . . . . . . . . . . . . . . . . . . . . . .  11
+     2.1.  Forwarding Basics . . . . . . . . . . . . . . . . . . . .  11
+       2.1.1.  MPLS Special-Purpose Labels . . . . . . . . . . . . .  12
+       2.1.2.  MPLS Differentiated Services  . . . . . . . . . . . .  13
+       2.1.3.  Time Synchronization  . . . . . . . . . . . . . . . .  14
+       2.1.4.  Uses of Multiple Label Stack Entries  . . . . . . . .  14
+       2.1.5.  MPLS Link Bundling  . . . . . . . . . . . . . . . . .  15
+       2.1.6.  MPLS Hierarchy  . . . . . . . . . . . . . . . . . . .  16
+       2.1.7.  MPLS Fast Reroute (FRR) . . . . . . . . . . . . . . .  16
+       2.1.8.  Pseudowire Encapsulation  . . . . . . . . . . . . . .  17
+         2.1.8.1.  Pseudowire Sequence Number  . . . . . . . . . . .  17
+       2.1.9.  Layer 2 and Layer 3 VPN . . . . . . . . . . . . . . .  19
+     2.2.  MPLS Multicast  . . . . . . . . . . . . . . . . . . . . .  20
+     2.3.  Packet Rates  . . . . . . . . . . . . . . . . . . . . . .  21
+     2.4.  MPLS Multipath Techniques . . . . . . . . . . . . . . . .  23
+       2.4.1.  Pseudowire Control Word . . . . . . . . . . . . . . .  24
+       2.4.2.  Large Microflows  . . . . . . . . . . . . . . . . . .  24
+       2.4.3.  Pseudowire Flow Label . . . . . . . . . . . . . . . .  25
+       2.4.4.  MPLS Entropy Label  . . . . . . . . . . . . . . . . .  25
+       2.4.5.  Fields Used for Multipath Load Balance  . . . . . . .  25
+         2.4.5.1.  MPLS Fields in Multipath  . . . . . . . . . . . .  26
+         2.4.5.2.  IP Fields in Multipath  . . . . . . . . . . . . .  27
+         2.4.5.3.  Fields Used in Flow Label . . . . . . . . . . . .  29
+         2.4.5.4.  Fields Used in Entropy Label  . . . . . . . . . .  29
+     2.5.  MPLS-TP and UHP . . . . . . . . . . . . . . . . . . . . .  30
+
+
+
+Villamizar, et al.            Informational                     [Page 2]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+     2.6.  Local Delivery of Packets . . . . . . . . . . . . . . . .  30
+       2.6.1.  DoS Protection  . . . . . . . . . . . . . . . . . . .  31
+       2.6.2.  MPLS OAM  . . . . . . . . . . . . . . . . . . . . . .  33
+       2.6.3.  Pseudowire OAM  . . . . . . . . . . . . . . . . . . .  34
+       2.6.4.  MPLS-TP OAM . . . . . . . . . . . . . . . . . . . . .  34
+       2.6.5.  MPLS OAM and Layer 2 OAM Interworking . . . . . . . .  35
+       2.6.6.  Extent of OAM Support by Hardware . . . . . . . . . .  36
+       2.6.7.  Support for IPFIX in Hardware . . . . . . . . . . . .  37
+     2.7.  Number and Size of Flows  . . . . . . . . . . . . . . . .  37
+   3.  Questions for Suppliers . . . . . . . . . . . . . . . . . . .  38
+     3.1.  Basic Compliance  . . . . . . . . . . . . . . . . . . . .  38
+     3.2.  Basic Performance . . . . . . . . . . . . . . . . . . . .  40
+     3.3.  Multipath Capabilities and Performance  . . . . . . . . .  41
+     3.4.  Pseudowire Capabilities and Performance . . . . . . . . .  41
+     3.5.  Entropy Label Support and Performance . . . . . . . . . .  42
+     3.6.  DoS Protection  . . . . . . . . . . . . . . . . . . . . .  42
+     3.7.  OAM Capabilities and Performance  . . . . . . . . . . . .  42
+   4.  Forwarding Compliance and Performance Testing . . . . . . . .  43
+     4.1.  Basic Compliance  . . . . . . . . . . . . . . . . . . . .  43
+     4.2.  Basic Performance . . . . . . . . . . . . . . . . . . . .  44
+     4.3.  Multipath Capabilities and Performance  . . . . . . . . .  45
+     4.4.  Pseudowire Capabilities and Performance . . . . . . . . .  46
+     4.5.  Entropy Label Support and Performance . . . . . . . . . .  46
+     4.6.  DoS Protection  . . . . . . . . . . . . . . . . . . . . .  47
+     4.7.  OAM Capabilities and Performance  . . . . . . . . . . . .  47
+   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  48
+   6.  Organization of References Section  . . . . . . . . . . . . .  50
+   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  50
+     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  50
+     7.2.  Informative References  . . . . . . . . . . . . . . . . .  53
+   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  59
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Villamizar, et al.            Informational                     [Page 3]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+1.  Introduction and Document Scope
+
+   The initial purpose of this document was to address concerns raised
+   on the MPLS WG mailing list about shortcomings in implementations of
+   MPLS forwarding.  Documenting existing misconceptions and potential
+   pitfalls might potentially avoid repeating past mistakes.  The
+   document has grown to address a broad set of forwarding requirements.
+
+   The focus of this document is MPLS forwarding, base pseudowire
+   forwarding, and MPLS Operations, Administration, and Maintenance
+   (OAM).  The use of pseudowire Control Word and the use of pseudowire
+   Sequence Number are discussed.  Specific pseudowire Attachment
+   Circuit (AC) and Native Service Processing (NSP) are out of scope.
+   Specific pseudowire applications, such as various forms of Virtual
+   Private Network (VPN), are out of scope.
+
+   MPLS support for multipath techniques is considered essential by many
+   service providers and is useful for other high-capacity networks.  In
+   order to obtain sufficient entropy from MPLS, traffic service
+   providers and others find it essential for the MPLS implementation to
+   interpret the MPLS payload as IPv4 or IPv6 based on the contents of
+   the first nibble of payload.  The use of IP addresses, the IP
+   protocol field, and UDP and TCP port number fields in multipath load
+   balancing are considered within scope.  The use of any other IP
+   protocol fields, such as tunneling protocols carried within IP, are
+   out of scope.
+
+   Implementation details are a local matter and are out of scope.  Most
+   interfaces today operate at 1 Gb/s or greater.  It is assumed that
+   all forwarding operations are implemented in specialized forwarding
+   hardware rather than on a general-purpose processor.  This is often
+   referred to as "fast path" and "slow path" processing.  Some
+   recommendations are made regarding implementing control or
+   management-plane functionality in specialized hardware or with
+   limited assistance from specialized hardware.  This advice is based
+   on expected control or management protocol loads and on the need for
+   denial of service (DoS) protection.
+
+1.1.  Abbreviations
+
+   The following abbreviations are used.
+
+   AC    Attachment Circuit ([RFC3985])
+
+   ACH   Associated Channel Header (pseudowires)
+
+   ACK   Acknowledgement (TCP flag and type of TCP packet)
+
+
+
+
+Villamizar, et al.            Informational                     [Page 4]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+   AIS   Alarm Indication Signal (MPLS-TP OAM)
+
+   ATM   Asynchronous Transfer Mode (legacy switched circuits)
+
+   BFD   Bidirectional Forwarding Detection
+
+   BGP   Border Gateway Protocol
+
+   CC-CV Continuity Check and Connectivity Verification
+
+   CE    Customer Edge ([RFC4364])
+
+   CPU   Central Processing Unit (computer or microprocessor)
+
+   CT    Class Type ([RFC4124])
+
+   CW    Control Word ([RFC4385])
+
+   DCCP  Datagram Congestion Control Protocol
+
+   DDoS  Distributed Denial of Service
+
+   DM    Delay Measurement (MPLS-TP OAM)
+
+   DSCP  Differentiated Services Code Point ([RFC2474])
+
+   DWDM  Dense Wave Division Multiplexing
+
+   DoS   Denial of Service
+
+   E-LSP Explicitly TC-encoded-PSC LSP ([RFC5462])
+
+   EBGP  External BGP
+
+   ECMP  Equal-Cost Multipath
+
+   ECN   Explicit Congestion Notification ([RFC3168] and [RFC5129])
+
+   EL    Entropy Label ([RFC6790])
+
+   ELI   Entropy Label Indicator ([RFC6790])
+
+   EXP   Experimental (field in MPLS renamed to "TC" in [RFC5462])
+
+   FEC   Forwarding Equivalence Classes ([RFC3031]); also Forward Error
+         Correction in other context
+
+   FR    Frame Relay (legacy switched circuits)
+
+
+
+Villamizar, et al.            Informational                     [Page 5]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+   FRR   Fast Reroute ([RFC4090])
+
+   G-ACh Generic Associated Channel ([RFC5586])
+
+   GAL   Generic Associated Channel Label ([RFC5586])
+
+   GFP   Generic Framing Procedure (used in OTN)
+
+   GMPLS Generalized MPLS ([RFC3471])
+
+   GTSM  Generalized TTL Security Mechanism ([RFC5082])
+
+   Gb/s  Gigabits per second (billion bits per second)
+
+   IANA  Internet Assigned Numbers Authority
+
+   ILM   Incoming Label Map ([RFC3031])
+
+   IP    Internet Protocol
+
+   IPVPN Internet Protocol VPN
+
+   IPv4  Internet Protocol version 4
+
+   IPv6  Internet Protocol version 6
+
+   L-LSP Label-Only-Inferred-PSC LSP ([RFC3270])
+
+   L2VPN Layer 2 VPN
+
+   LDP   Label Distribution Protocol ([RFC5036])
+
+   LER   Label Edge Router ([RFC3031])
+
+   LM    Loss Measurement (MPLS-TP OAM)
+
+   LSP   Label Switched Path ([RFC3031])
+
+   LSR   Label Switching Router ([RFC3031])
+
+   MP2MP Multipoint to Multipoint
+
+   MPLS  Multiprotocol Label Switching ([RFC3031])
+
+   MPLS-TP  MPLS Transport Profile ([RFC5317])
+
+   Mb/s  Megabits per second (million bits per second)
+
+
+
+
+Villamizar, et al.            Informational                     [Page 6]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+   NSP   Native Service Processing ([RFC3985])
+
+   NTP   Network Time Protocol
+
+   OAM   Operations, Administration, and Maintenance ([RFC6291])
+
+   OOB   Out-of-band (not carried within a data channel)
+
+   OTN   Optical Transport Network
+
+   P     Provider router ([RFC4364])
+
+   P2MP  Point to Multipoint
+
+   PE    Provider Edge router ([RFC4364])
+
+   PHB   Per-Hop Behavior ([RFC2475])
+
+   PHP   Penultimate Hop Popping ([RFC3443])
+
+   POS   PPP over SONET
+
+   PSC   This abbreviation has multiple interpretations.
+
+         1.  Packet Switch Capable ([RFC3471]
+
+         2.  PHB Scheduling Class ([RFC3270])
+
+         3.  Protection State Coordination ([RFC6378])
+
+   PTP   Precision Time Protocol
+
+   PW    Pseudowire
+
+   QoS   Quality of Service
+
+   RA    Router Alert ([RFC3032])
+
+   RDI   Remote Defect Indication (MPLS-TP OAM)
+
+   RSVP-TE  RSVP Traffic Engineering
+
+   RTP   Real-time Transport Protocol
+
+   SCTP  Stream Control Transmission Protocol
+
+   SDH   Synchronous Data Hierarchy (European SONET, a form of TDM)
+
+
+
+
+Villamizar, et al.            Informational                     [Page 7]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+   SONET Synchronous Optical Network (US SDH, a form of TDM)
+
+   T-LDP Targeted LDP (LDP sessions over more than one hop)
+
+   TC    Traffic Class ([RFC5462])
+
+   TCP   Transmission Control Protocol
+
+   TDM   Time-Division Multiplexing (legacy encapsulations)
+
+   TOS   Type of Service (see [RFC2474])
+
+   TTL   Time-to-live (a field in IP and MPLS headers)
+
+   UDP   User Datagram Protocol
+
+   UHP   Ultimate Hop Popping (opposite of PHP)
+
+   VCCV  Virtual Circuit Connectivity Verification ([RFC5085])
+
+   VLAN  Virtual Local Area Network (Ethernet)
+
+   VOQ   Virtual Output Queuing (switch fabric design)
+
+   VPN   Virtual Private Network
+
+   WG    Working Group
+
+1.2.  Use of Requirements Language
+
+   This document is Informational.  The uppercase [RFC2119] key words
+   "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are used in
+   this document in the following cases.
+
+   1.  RFC 2119 keywords are used where requirements stated in this
+       document are called for in referenced RFCs.  In most cases, the
+       RFC containing the requirement is cited within the statement
+       using an RFC 2119 keyword.
+
+   2.  RFC 2119 keywords are used where explicitly noted that the
+       keywords indicate that operator experiences indicate a
+       requirement, but there are no existing RFC requirements.
+
+   Advice provided by this document may be ignored by implementations.
+   Similarly, implementations not claiming conformance to specific RFCs
+   may ignore the requirements of those RFCs.  In both cases,
+   implementers should consider the risk of doing so.
+
+
+
+
+Villamizar, et al.            Informational                     [Page 8]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+1.3.  Apparent Misconceptions
+
+   In early generations of forwarding silicon (which might now be behind
+   us), there apparently were some misconceptions about MPLS.  The
+   following statements provide clarifications.
+
+   1.  There are practical reasons to have more than one or two labels
+       in an MPLS label stack.  Under some circumstances, the label
+       stack can become quite deep.  See Section 2.1.
+
+   2.  The label stack MUST be considered to be arbitrarily deep.
+       Section 3.27.4 ("Hierarchy: LSP Tunnels within LSPs") of RFC 3031
+       states "The label stack mechanism allows LSP tunneling to nest to
+       any depth" [RFC3031].  If a bottom of the label stack cannot be
+       found, but sufficient number of labels exist to forward, an LSR
+       MUST forward the packet.  An LSR MUST NOT assume the packet is
+       malformed unless the end of packet is found before the bottom of
+       the stack.  See Section 2.1.
+
+   3.  In networks where deep label stacks are encountered, they are not
+       rare.  Full packet rate performance is required regardless of
+       label stack depth, except where multiple pop operations are
+       required.  See Section 2.1.
+
+   4.  Research has shown that long bursts of short packets with 40-byte
+       or 44-byte IP payload sizes in these bursts are quite common.
+       This is due to TCP ACK compression [ACK-compression].  The
+       following two sub-bullets constitute advice that reflects very
+       common nonnegotiable requirements of providers.  Implementers may
+       ignore this advice but should consider the risk of doing so.
+
+       A.  A forwarding engine SHOULD, if practical, be able to sustain
+           an arbitrarily long sequence of small packets arriving at
+           full interface rate.
+
+       B.  If indefinitely sustained full packet rate for small packets
+           is not practical, a forwarding engine MUST be able to buffer
+           a long sequence of small packets inbound to the on-chip
+           decision engine and sustain full interface rate for some
+           reasonable average packet rate.  Absent this small on-chip
+           buffering, QoS-agnostic packet drops can occur.
+
+       See Section 2.3.
+
+   5.  The implementations and system designs MUST support pseudowire
+       Control Word (CW) if MPLS-TP is supported or if ACH [RFC5586] is
+       being used on a pseudowire.  The implementation and system
+       designs SHOULD support pseudowire CW even if MPLS-TP and ACH
+
+
+
+Villamizar, et al.            Informational                     [Page 9]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+       [RFC5586] are not used, using instead CW and VCCV Type 1
+       [RFC5085] to allow the use of multipath in the underlying network
+       topology without impacting the PW traffic.  [RFC7079] does note
+       that there are still some deployments where the CW is not always
+       used.  It also notes that many service providers do enable the
+       CW.  See Section 2.4.1 for more discussion on why deployments
+       SHOULD enable the pseudowire CW.
+
+   The following statements provide clarification regarding more recent
+   requirements that are often missed.
+
+   1.  The implementer and system designer SHOULD support adding a
+       pseudowire Flow Label [RFC6391].  Deployments MAY enable this
+       feature for appropriate pseudowire types.  See Section 2.4.3.
+
+   2.  The implementer and system designer SHOULD support adding an MPLS
+       Entropy Label [RFC6790].  Deployments MAY enable this feature.
+       See Section 2.4.4.
+
+   Non-IETF definitions of MPLS exist, and these should not be used as
+   normative texts in place of the relevant IETF RFCs.  [RFC5704]
+   documents incompatibilities between the IETF definition of MPLS and
+   one such alternative MPLS definition, which led to significant issues
+   in the resulting non-IETF specification.
+
+1.4.  Target Audience
+
+   This document is intended for multiple audiences: implementer
+   (implementing MPLS forwarding in silicon or in software); systems
+   designer (putting together a MPLS forwarding systems); deployer
+   (running an MPLS network).  These guidelines are intended to serve
+   the following purposes:
+
+   1.  Explain what to do and what not to do when a deep label stack is
+       encountered. (audience: implementer)
+
+   2.  Highlight pitfalls to look for when implementing an MPLS
+       forwarding chip. (audience: implementer)
+
+   3.  Provide a checklist of features and performance specifications to
+       request.  (audience: systems designer, deployer)
+
+   4.  Provide a set of tests to perform.  (audience: systems designer,
+       deployer).
+
+
+
+
+
+
+
+Villamizar, et al.            Informational                    [Page 10]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+   The implementer, systems designer, and deployer have a transitive
+   supplier-customer relationship.  It is in the best interest of the
+   supplier to review their product against their customer's checklist
+   and secondary customer's checklist if applicable.
+
+   This document identifies and explains many details and potential
+   pitfalls of MPLS forwarding.  It is likely that the identified set of
+   potential pitfalls will later prove to be an incomplete set.
+
+2.  Forwarding Issues
+
+   A brief review of forwarding issues is provided in the subsections
+   that follow.  This section provides some background on why some of
+   these requirements exist.  The questions to ask of suppliers is
+   covered in Section 3.  Some guidelines for testing are provided in
+   Section 4.
+
+2.1.  Forwarding Basics
+
+   Basic MPLS architecture and MPLS encapsulation, and therefore packet
+   forwarding, are defined in [RFC3031] and [RFC3032].  RFC 3031 and RFC
+   3032 are somewhat LDP centric.  RSVP-TE supports traffic engineering
+   (TE) and fast reroute, features that LDP lacks.  The base document
+   for MPLS RSVP-TE is [RFC3209].
+
+   A few RFCs update RFC 3032.  Those with impact on forwarding include
+   the following.
+
+   1.  TTL processing is clarified in [RFC3443].
+
+   2.  The use of MPLS Explicit NULL is modified in [RFC4182].
+
+   3.  Differentiated Services is supported by [RFC3270] and [RFC4124].
+       The "EXP" field is renamed to "Traffic Class" in [RFC5462],
+       removing any misconception that it was available for
+       experimentation or could be ignored.
+
+   4.  ECN is supported by [RFC5129].
+
+   5.  The MPLS G-ACh and GAL are defined in [RFC5586].
+
+   6.  [RFC5332] redefines the two data link layer codepoints for MPLS
+       packets.
+
+   Tunneling encapsulations carrying MPLS, such as MPLS in IP [RFC4023],
+   MPLS in GRE [RFC4023], MPLS in L2TPv3 [RFC4817], or MPLS in UDP
+   [MPLS-IN-UDP], are out of scope.
+
+
+
+
+Villamizar, et al.            Informational                    [Page 11]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+   Other RFCs have implications to MPLS Forwarding and do not update RFC
+   3032 or RFC 3209, including:
+
+   1.  The pseudowire (PW) Associated Channel Header (ACH) is defined by
+       [RFC5085] and was later generalized by the MPLS G-ACh [RFC5586].
+
+   2.  The Entropy Label Indicator (ELI) and Entropy Label (EL) are
+       defined by [RFC6790].
+
+   A few RFCs update RFC 3209.  Those that are listed as updating RFC
+   3209 generally impact only RSVP-TE signaling.  Forwarding is modified
+   by major extensions built upon RFC 3209.
+
+   RFCs that impact forwarding are discussed in the following
+   subsections.
+
+2.1.1.  MPLS Special-Purpose Labels
+
+   [RFC3032] specifies that label values 0-15 are special-purpose labels
+   with special meanings.  [RFC7274] renamed these from the term
+   "reserved labels" used in [RFC3032] to "special-purpose labels".
+   Three values of NULL label are defined (two of which are later
+   updated by [RFC4182]) and a Router Alert Label is defined.  The
+   original intent was that special-purpose labels, except the NULL
+   labels, could be sent to the routing engine CPU rather than be
+   processed in forwarding hardware.  Hardware support is required by
+   new RFCs such as those defining Entropy Label and OAM processed as a
+   result of receiving a GAL.  For new special-purpose labels, some
+   accommodation is needed for LSRs that will send the labels to a
+   general-purpose CPU or other highly programmable hardware.  For
+   example, ELI will only be sent to LSRs that have signaled support for
+   [RFC6790], and a high OAM packet rate must be negotiated among
+   endpoints.
+
+   [RFC3429] reserves a label for ITU-T Y.1711; however, Y.1711 does not
+   work with multipath and its use is strongly discouraged.
+
+   The current list of special-purpose labels can be found on the
+   "Multiprotocol Label Switching Architecture (MPLS) Label Values"
+   registry reachable at IANA's pages at <http://www.iana.org>.
+
+   [RFC7274] introduces an IANA "Extended Special-Purpose MPLS Label
+   Values" registry and makes use of the "extension" label, label 15, to
+   indicate that the next label is an extended special-purpose label and
+   requires special handling.  The range of only 16 values for special-
+   purpose labels allows a table to be used.  The range of extended
+   special-purpose labels with 20 bits available for use may have to be
+   handled in some other way in the unlikely event that in the future
+
+
+
+Villamizar, et al.            Informational                    [Page 12]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+   the range of currently reserved values 256-1048575 is used.  If only
+   the Standards Action range, 16-239, and the Experimental range,
+   240-255, are used, then a table of 256 entries can be used.
+
+   Unknown special-purpose labels and unknown extended special-purpose
+   labels are handled the same.  When an unknown special-purpose label
+   is encountered or a special purpose label not directly handled in
+   forwarding hardware is encountered, the packet should be sent to a
+   general-purpose CPU by default.  If this capability is supported,
+   there must be an option to either drop or rate limit such packets
+   based on the value of each special-purpose label.
+
+2.1.2.  MPLS Differentiated Services
+
+   [RFC2474] deprecates the IP Type of Service (TOS) and IP Precedence
+   (Prec) fields and replaces them with the Differentiated Services
+   Field more commonly known as the Differentiated Services Code Point
+   (DSCP) field.  [RFC2475] defines the Differentiated Services
+   architecture, which in other forums, is often called a Quality of
+   Service (QoS) architecture.
+
+   MPLS uses the Traffic Class (TC) field to support Differentiated
+   Services [RFC5462].  There are two primary documents describing how
+   DSCP is mapped into TC.
+
+   1.  [RFC3270] defines E-LSP and L-LSP.  E-LSP uses a static mapping
+       of DSCP into TC.  L-LSP uses a per-LSP mapping of DSCP into TC,
+       with one PHB Scheduling Class (PSC) per L-LSP.  Each PSC can use
+       multiple Per-Hop Behavior (PHB) values.  For example, the Assured
+       Forwarding service defines three PSCs, each with three PHB
+       [RFC2597].
+
+   2.  [RFC4124] defines assignment of a class-type (CT) to an LSP,
+       where a per-CT static mapping of TC to PHB is used.  [RFC4124]
+       provides a means to support up to eight E-LSP-like mappings of
+       DSCP to TC.
+
+   To meet Differentiated Services requirements specified in [RFC3270],
+   the following forwarding requirements must be met.  An ingress LER
+   MUST be able to select an LSP and then apply a per-LSP map of DSCP
+   into TC.  A midpoint LSR MUST be able to apply a per-LSP map of TC to
+   PHB.  The number of mappings supported will be far less than the
+   number of LSPs supported.
+
+   To meet Differentiated Services requirements specified in [RFC4124],
+   the following forwarding requirements must be met.  An ingress LER
+   MUST be able to select an LSP and then apply a per-LSP map of DSCP
+   into TC.  A midpoint LSR MUST be able to map LSP number to Class Type
+
+
+
+Villamizar, et al.            Informational                    [Page 13]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+   (CT), then use a per-CT map to map TC to PHB.  Since there are only
+   eight allowed values of CT, only eight maps of TC to PHB need to be
+   supported.  The LSP label can be used directly to find the TC-to-PHB
+   mapping, as is needed to support L-LSPs as defined by [RFC3270].
+
+   While support for [RFC4124] and not [RFC3270] would allow support for
+   only eight mappings of TC to PHB, it is common to support both and
+   simply state a limit on the number of unique TC-to-PHB mappings that
+   can be supported.
+
+2.1.3.  Time Synchronization
+
+   PTP or NTP may be carried over MPLS [TIMING-OVER-MPLS].  Generally,
+   NTP will be carried within IP, and IP will be carried in MPLS
+   [RFC5905].  Both PTP and NTP benefit from accurate timestamping of
+   incoming packets and the ability to insert accurate timestamps in
+   outgoing packets.  PTP correction that occurs when forwarding
+   requires updating a timestamp compensation field based on the
+   difference between packet arrival at an LSR and packet transmit time
+   at that same LSR.
+
+   Since the label stack depth may vary, hardware should allow a
+   timestamp to be placed in an outgoing packet at any specified byte
+   position.  It may be necessary to modify Layer 2 checksums or frame
+   check sequences after insertion.  PTP and NTP timestamp formats
+   differ in such a way as to require different implementations of the
+   timestamp correction.  If NTP or PTP is carried over UDP/IP or
+   UDP/IP/MPLS, the UDP checksum will also have to be updated.
+
+   Accurate time synchronization, in addition to being generally useful,
+   is required for MPLS-TP Delay Measurement (DM) OAM.  See
+   Section 2.6.4.
+
+2.1.4.  Uses of Multiple Label Stack Entries
+
+   MPLS deployments in the early part of the prior decade (circa 2000)
+   tended to support either LDP or RSVP-TE.  LDP was favored by some for
+   its ability to scale to a very large number of PE devices at the edge
+   of the network, without adding deployment complexity.  RSVP-TE was
+   favored, generally in the network core, where traffic engineering
+   and/or fast reroute were considered important.
+
+   Both LDP and RSVP-TE are used simultaneously within major service
+   provider networks using a technique known as "LDP over RSVP-TE
+   Tunneling".  This technique allows service providers to carry LDP
+   tunnels inside RSVP-TE tunnels.  This makes it possible to take
+   advantage of the traffic engineering and fast reroute on more
+   expensive intercity and intercontinental transport paths.  The
+
+
+
+Villamizar, et al.            Informational                    [Page 14]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+   ingress RSVP-TE PE places many LDP tunnels on a single RSVP-TE LSP
+   and carries it to the egress RSVP-TE PE.  The LDP PEs are situated
+   further from the core, for example, within a metro network.  LDP over
+   RSVP-TE tunneling requires a minimum of two MPLS labels: one each for
+   LDP and RSVP-TE.
+
+   The use of MPLS FRR [RFC4090] might add one more label to MPLS
+   traffic but only when FRR protection is in use (active).  If LDP over
+   RSVP-TE is in use, and FRR protection is in use, then at least three
+   MPLS labels are present on the label stack on the links through which
+   the Bypass LSP traverses.  FRR is covered in Section 2.1.7.
+
+   LDP L2VPN, LDP IPVPN, BGP L2VPN, and BGP IPVPN added support for VPN
+   services that are deployed by the vast majority of service providers.
+   These VPN services added yet another label, bringing the label stack
+   depth (when FRR is active) to four.
+
+   Pseudowires and VPN are discussed in further detail in Sections 2.1.8
+   and 2.1.9.
+
+   MPLS hierarchy as described in [RFC4206] and updated by [RFC7074] can
+   in principle add at least one additional label.  MPLS hierarchy is
+   discussed in Section 2.1.6.
+
+   Other features such as Entropy Label (discussed in Section 2.4.4) and
+   Flow Label (discussed in Section 2.4.3) can add additional labels to
+   the label stack.
+
+   Although theoretical scenarios can easily result in eight or more
+   labels, such cases are rare if they occur at all today.  For the
+   purpose of forwarding, only the top label needs to be examined if PHP
+   is used, and a few more if UHP is used (see Section 2.5).  For deep
+   label stacks, quite a few labels may have to be examined for the
+   purpose of load balancing across parallel links (see Section 2.4);
+   however, this depth can be bounded by a provider through use of
+   Entropy Label.
+
+   Other creative uses of MPLS within the IETF, such as the use of MPLS
+   label stack in source routing, may result in label stacks that are
+   considerably deeper than those encountered today.
+
+2.1.5.  MPLS Link Bundling
+
+   MPLS Link Bundling was the first RFC to address the need for multiple
+   parallel links between nodes [RFC4201].  MPLS Link Bundling is
+   notable in that it tried not to change MPLS forwarding, except in
+
+
+
+
+
+Villamizar, et al.            Informational                    [Page 15]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+   specifying the "all-ones" component link.  MPLS Link Bundling is
+   seldom if ever deployed.  Instead, multipath techniques described in
+   Section 2.4 are used.
+
+2.1.6.  MPLS Hierarchy
+
+   MPLS hierarchy is defined in [RFC4206] and updated by [RFC7074].
+   Although RFC 4206 is considered part of GMPLS, the Packet Switching
+   Capable (PSC) portion of the MPLS hierarchy is applicable to MPLS and
+   may be supported in an otherwise GMPLS-free implementation.  The MPLS
+   PSC hierarchy remains the most likely means of providing further
+   scaling in an RSVP-TE MPLS network, particularly where the network is
+   designed to provide RSVP-TE connectivity to the edges.  This is the
+   case for envisioned MPLS-TP networks.  The use of the MPLS PSC
+   hierarchy can add at least one additional label to a label stack,
+   though it is likely that only one layer of PSC will be used in the
+   near future.
+
+2.1.7.  MPLS Fast Reroute (FRR)
+
+   Fast reroute is defined by [RFC4090].  Two significantly different
+   methods are defined in RFC 4090: the "One-to-One Backup" method,
+   which uses the "Detour LSP", and the "Facility Backup", which uses a
+   "bypass tunnel".  These are commonly referred to as the detour and
+   bypass methods, respectively.
+
+   The detour method makes use of a presignaled LSP.  Hardware
+   assistance may be needed for detour FRR in order to accomplish local
+   repair of a large number of LSPs within the target of tens of
+   milliseconds.  For each affected LSP, a swap operation must be
+   reprogrammed or otherwise switched over.  The use of detour FRR
+   doubles the number of LSPs terminating at any given hop and will
+   increase the number of LSPs within a network by a factor dependent on
+   the average detour path length.
+
+   The bypass method makes use of a tunnel that is unused when no fault
+   exists but may carry many LSPs when a local repair is required.
+   There is no presignaling indicating which working LSP will be
+   diverted into any specific bypass LSP.  If interface label space is
+   used, the bypass LSP MUST extend one hop beyond the merge point,
+   except if the merge point is the egress and PHP is used.  If the
+   bypass LSPs are not extended in this way, then the merge LSR (egress
+   LSR of the bypass LSP) MUST use platform label space (as defined in
+   [RFC3031]) so that an LSP working path on any given interface can be
+   backed up using a bypass LSP terminating on any other interface.
+   Hardware assistance may be needed to accomplish local repair of a
+   large number of LSPs within the target of tens of milliseconds.  For
+   each affected LSP a swap operation must be reprogrammed or otherwise
+
+
+
+Villamizar, et al.            Informational                    [Page 16]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+   switched over with an additional push of the bypass LSP label.  The
+   use of platform label space impacts the size of the LSR ILM for an
+   LSR with a very large number of interfaces.
+
+   IP/LDP Fast Reroute (IP/LDP FRR) [RFC5714] is also applicable in MPLS
+   networks.  ECMP and Loop-Free Alternates (LFAs) [RFC5286] are well-
+   established IP/LDP FRR techniques and were the first methods to be
+   widely deployed.  Work on IP/LDP FRR is ongoing within the IETF
+   RTGWG.  Two topics actively discussed in RTGWG are microloops and
+   partial coverage of the established techniques in some network
+   topologies.  [RFC5715] covers the topic of IP/LDP Fast Reroute
+   microloops and microloop prevention.  RTGWG has developed additional
+   IP/LDP FRR techniques to handle coverage concerns.  RTGWG is
+   extending LFA through the use of remote LFA [REMOTE-LFA].  Other
+   techniques that require new forwarding paths to be established are
+   also under consideration, including the IPFRR "not-via" technique
+   defined in [RFC6981] and maximally redundant trees (MRT) [MRT].
+   ECMP, LFA (but not remote LFA), and MRT swap the top label to an
+   alternate MPLS label.  The other methods operate in a similar manner
+   to the facility backup described in RFC 4090 and push an additional
+   label.  IP/LDP FRR methods that push more than one label have been
+   suggested but are in early discussion.
+
+2.1.8.  Pseudowire Encapsulation
+
+   The pseudowire (PW) architecture is defined in [RFC3985].  A
+   pseudowire, when carried over MPLS, adds one or more additional label
+   entries to the MPLS label stack.  A PW Control Word is defined in
+   [RFC4385] with motivation for defining the Control Word in [RFC4928].
+   The PW Associated Channel defined in [RFC4385] is used for OAM in
+   [RFC5085].  The PW Flow Label is defined in [RFC6391] and is
+   discussed further in this document in Section 2.4.3.
+
+   There are numerous pseudowire encapsulations, supporting emulation of
+   services such as Frame Relay, ATM, Ethernet, TDM, and SONET/SDH over
+   packet switched networks (PSNs) using IP or MPLS.
+
+   The pseudowire encapsulation is out of scope for this document.
+   Pseudowire impact on MPLS forwarding at the midpoint LSR is within
+   scope.  The impact on ingress MPLS push and egress MPLS UHP pop are
+   within scope.  While pseudowire encapsulation is out of scope, some
+   advice is given on Sequence Number support.
+
+2.1.8.1.  Pseudowire Sequence Number
+
+   Pseudowire (PW) Sequence Number support is most important for PW
+   payload types with a high expectation of lossless and/or in-order
+   delivery.  Identifying lost PW packets and the exact amount of lost
+
+
+
+Villamizar, et al.            Informational                    [Page 17]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+   payload is critical for PW services that maintain bit timing, such as
+   Time Division Multiplexing (TDM) services since these services MUST
+   compensate lost payload on a bit-for-bit basis.
+
+   With PW services that maintain bit timing, packets that have been
+   received out of order also MUST be identified and MAY be either
+   reordered or dropped.  Resequencing requires, in addition to sequence
+   numbering, a "reorder buffer" in the egress PE, and the ability to
+   reorder is limited by the depth of this buffer.  The down side of
+   maintaining a large reorder buffer is added end-to-end service delay.
+
+   For PW services that maintain bit timing or any other service where
+   jitter must be bounded, a jitter buffer is always necessary.  The
+   jitter buffer is needed regardless of whether reordering is done.  In
+   order to be effective, a reorder buffer must often be larger than a
+   jitter buffer needs to be, thus creating a tradeoff between reducing
+   loss and minimizing delay.
+
+   PW services that are not timing critical bit streams in nature are
+   cell oriented or frame oriented.  Though resequencing support may be
+   beneficial to PW cell- and frame-oriented payloads such as ATM, FR,
+   and Ethernet, this support is desirable but not required.
+   Requirements to handle out-of-order packets at all vary among
+   services and deployments.  For example, for Ethernet PW, occasional
+   (very rare) reordering is usually acceptable.  If the Ethernet PW is
+   carrying MPLS-TP, then this reordering may be acceptable.
+
+   Reducing jitter is best done by an end-system, given that the
+   tradeoff of loss vs. delay varies among services.  For example, with
+   interactive real-time services, low delay is preferred, while with
+   non-interactive (one-way) real-time services, low loss is preferred.
+   The same end-site may be receiving both types of traffic.  Regardless
+   of this, bounded jitter is sometimes a requirement for specific
+   deployments.
+
+   Packet reordering should be rare except in a small number of
+   circumstances, most of which are due to network design or equipment
+   design errors:
+
+   1.  The most common case is where reordering is rare, occurring only
+       when a network or equipment fault forces traffic on a new path
+       with different delay.  The packet loss that accompanies a network
+       or equipment fault is generally more disruptive than any
+       reordering that may occur.
+
+
+
+
+
+
+
+Villamizar, et al.            Informational                    [Page 18]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+   2.  A path change can be caused by reasons other than a network or
+       equipment fault, such as an administrative routing change.  This
+       may result in packet reordering but generally without any packet
+       loss.
+
+   3.  If the edge is not using pseudowire Control Word (CW) and the
+       core is using multipath, reordering will be far more common.  If
+       this is occurring, using CW on the edge will solve the problem.
+       Without CW, resequencing is not possible since the Sequence
+       Number is contained in the CW.
+
+   4.  Another avoidable case is where some core equipment has multipath
+       and for some reason insists on periodically installing a new
+       random number as the multipath hash seed.  If supporting MPLS-TP,
+       equipment MUST provide a means to disable periodic hash
+       reseeding, and deployments MUST disable periodic hash reseeding.
+       Operator experience dictates that even if not supporting MPLS-TP,
+       equipment SHOULD provide a means to disable periodic hash
+       reseeding, and deployments SHOULD disable periodic hash
+       reseeding.
+
+   In provider networks that use multipath techniques and that may
+   occasionally rebalance traffic or that may change PW paths
+   occasionally for other reasons, reordering may be far more common
+   than loss.  Where reordering is more common than loss, resequencing
+   packets is beneficial, rather than dropping packets at egress when
+   out-of-order arrival occurs.  Resequencing is most important for PW
+   payload types with a high expectation of lossless delivery since in
+   such cases out-of-order delivery within the network results in PW
+   loss.
+
+2.1.9.  Layer 2 and Layer 3 VPN
+
+   Layer 2 VPN [RFC4664] and Layer 3 VPN [RFC4110] add one or more label
+   entry to the MPLS label stack.  VPN encapsulations are out of scope
+   for this document.  Their impact on forwarding at the midpoint LSR
+   are within scope.
+
+   Any of these services may be used on an ingress and egress that are
+   MPLS Entropy Label enabled (see Section 2.4.4 for discussion of
+   Entropy Label); this would add an additional two labels to the MPLS
+   label stack.  The need to provide a useful Entropy Label value
+   impacts the requirements of the VPN ingress LER but is out of scope
+   for this document.
+
+
+
+
+
+
+
+Villamizar, et al.            Informational                    [Page 19]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+2.2.  MPLS Multicast
+
+   MPLS Multicast encapsulation is clarified in [RFC5332].  MPLS
+   Multicast may be signaled using RSVP-TE [RFC4875] or LDP [RFC6388].
+
+   [RFC4875] defines a root-initiated RSVP-TE LSP setup rather than the
+   leaf-initiated join used in IP multicast.  [RFC6388] defines a leaf-
+   initiated LDP setup.  Both [RFC4875] and [RFC6388] define point-to-
+   multipoint (P2MP) LSP setup.  [RFC6388] also defined multipoint-to-
+   multipoint (MP2MP) LSP setup.
+
+   The P2MP LSPs have a single source.  An LSR may be a leaf node, an
+   intermediate node, or a "bud" node.  A bud serves as both a leaf and
+   intermediate.  At a leaf, an MPLS pop is performed.  The payload may
+   be an IP multicast packet that requires further replication.  At an
+   intermediate node, an MPLS swap operation is performed.  The bud
+   requires that both a pop operation and a swap operation be performed
+   for the same incoming packet.
+
+   One strategy to support P2MP functionality is to pop at the LSR
+   interface serving as ingress to the P2MP traffic and then optionally
+   push labels at each LSR interface serving as egress to the P2MP
+   traffic at that same LSR.  A given LSR egress chip may support
+   multiple egress interfaces, each of which requires a copy, but each
+   with a different set of added labels and Layer 2 encapsulation.  Some
+   physical interfaces may have multiple sub-interfaces (such as
+   Ethernet VLAN or channelized interfaces), each requiring a copy.
+
+   If packet replication is performed at LSR ingress, then the ingress
+   interface performance may suffer.  If the packet replication is
+   performed within a LSR switching fabric and at LSR egress, congestion
+   of egress interfaces cannot make use of backpressure to ingress
+   interfaces using techniques such as virtual output queuing (VOQ).  If
+   buffering is primarily supported at egress, then the need for
+   backpressure is minimized.  There may be no good solution for high
+   volumes of multicast traffic if VOQ is used.
+
+   Careful consideration should be given to the performance
+   characteristics of high-fanout multicast for equipment that is
+   intended to be used in such a role.
+
+   MP2MP LSPs differ in that any branch may provide an input, including
+   a leaf.  Packets must be replicated onto all other branches.  This
+   forwarding is often implemented as multiple P2MP forwarding trees,
+   one for each potential input interface at a given LSR.
+
+
+
+
+
+
+Villamizar, et al.            Informational                    [Page 20]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+2.3.  Packet Rates
+
+   While average packet size of Internet traffic may be large, long
+   sequences of small packets have both been predicted in theory and
+   observed in practice.  Traffic compression and TCP ACK compression
+   can conspire to create long sequences of packets of 40-44 bytes in
+   payload length.  If carried over Ethernet, the 64-byte minimum
+   payload applies, yielding a packet rate of approximately 150 Mpps
+   (million packets per second) for the duration of the burst on a
+   nominal 100 Gb/s link.  The peak rate for other encapsulations can be
+   as high as 250 Mpps (for example, when IP or MPLS is encapsulated
+   using GFP over OTN ODU4).
+
+   It is possible that the packet rates achieved by a specific
+   implementation are acceptable for a minimum payload size, such as a
+   64-byte (64B) payload for Ethernet, but the achieved rate declines to
+   an unacceptable level for other packet sizes, such as a 65B payload.
+   There are other packet rates of interest besides TCP ACK.  For
+   example, a TCP ACK carried over an Ethernet PW over MPLS over
+   Ethernet may occupy 82B or 82B plus an increment of 4B if additional
+   MPLS labels are present.
+
+   A graph of packet rate vs. packet size often displays a sawtooth.
+   The sawtooth is commonly due to a memory bottleneck and memory
+   widths, sometimes an internal cache, but often a very wide external
+   buffer memory interface.  In some cases, it may be due to a fabric
+   transfer width.  A fine packing, rounding up to the nearest 8B or 16B
+   will result in a fine sawtooth with small degradation for 65B, and
+   even less for 82B packets.  A coarse packing, rounding up to 64B can
+   yield a sharper drop in performance for 65B packets, or perhaps more
+   important, a larger drop for 82B packets.
+
+   The loss of some TCP ACK packets are not the primary concern when
+   such a burst occurs.  When a burst occurs, any other packets,
+   regardless of packet length and packet QoS are dropped once on-chip
+   input buffers prior to the decision engine are exceeded.  Buffers in
+   front of the packet decision engine are often very small or
+   nonexistent (less than one packet of buffer) causing significant QoS-
+   agnostic packet drop.
+
+   Internet service providers and content providers at one time
+   specified full rate forwarding with 40-byte payload packets as a
+   requirement.  Today, this requirement often can be waived if the
+   provider can be convinced that when long sequences of short packets
+   occur no packets will be dropped.
+
+
+
+
+
+
+Villamizar, et al.            Informational                    [Page 21]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+   Many equipment suppliers have pointed out that the extra cost in
+   designing hardware capable of processing the minimum size packets at
+   full line rate is significant for very-high-speed interfaces.  If
+   hardware is not capable of processing the minimum size packets at
+   full line rate, then that hardware MUST be capable of handling large
+   bursts of small packets, a condition that is often observed.  This
+   level of performance is necessary to meet Differentiated Services
+   [RFC2475] requirements; without it, packets are lost prior to
+   inspection of the IP DSCP field [RFC2474] or MPLS TC field [RFC5462].
+
+   With adequate on-chip buffers before the packet decision engine, an
+   LSR can absorb a long sequence of short packets.  Even if the output
+   is slowed to the point where light congestion occurs, the packets,
+   having cleared the decision process, can make use of larger VOQ or
+   output side buffers and be dealt with according to configured QoS
+   treatment, rather than dropped completely at random.
+
+   The buffering before the packet decision engine should be arranged
+   such that 1) it can hold a relatively large number of small packets,
+   2) it can hold a small number of large packets, and 3) it can hold a
+   mix of packets of different sizes.
+
+   These on-chip buffers need not contribute significant delay since
+   they are only used when the packet decision engine is unable to keep
+   up, not in response to congestion, plus these buffers are quite
+   small.  For example, an on-chip buffer capable of handling 4K packets
+   of 64 bytes in length, or 256KB, corresponds to 200 microseconds on a
+   10 Gb/s link and 20 microseconds on a 100 Gb/s link.  If the packet
+   decision engine is capable of handling packets at 90% of the full
+   rate for small packets, then the maximum added delay is 20
+   microseconds and 2 microseconds, respectively, and this delay only
+   applies if a 4K burst of short packets occurs.  When no burst of
+   short packets was being processed, no delay is added.  These buffers
+   are only needed on high-speed interfaces where it is difficult to
+   process small packets at full line rate.
+
+   Packet rate requirements apply regardless of which network tier the
+   equipment is deployed in.  Whether deployed in the network core or
+   near the network edges, one of the two conditions MUST be met if
+   Differentiated Services requirements are to be met:
+
+   1.  Packets must be processed at full line rate with minimum-sized
+       packets.  -OR-
+
+   2.  Packets must be processed at a rate well under generally accepted
+       average packet sizes, with sufficient buffering prior to the
+       packet decision engine to accommodate long bursts of small
+       packets.
+
+
+
+Villamizar, et al.            Informational                    [Page 22]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+2.4.  MPLS Multipath Techniques
+
+   In any large provider, service providers, and content providers,
+   hash-based multipath techniques are used in the core and in the edge.
+   In many of these providers, hash-based multipath is also used in the
+   larger metro networks.
+
+   For good reason, the Differentiated Services requirements dictate
+   that packets within a common microflow SHOULD NOT be reordered
+   [RFC2474].  Service providers generally impose stronger requirements,
+   commonly requiring that packets within a microflow MUST NOT be
+   reordered except in rare circumstances such as load balancing across
+   multiple links, path change for load balancing, or path change for
+   other reason.
+
+   The most common multipath techniques are ECMP applied at the IP
+   forwarding level, Ethernet Link Aggregation Group (LAG) with
+   inspection of the IP payload, and multipath on links carrying both IP
+   and MPLS, where the IP header is inspected below the MPLS label
+   stack.  In most core networks, the vast majority of traffic is MPLS
+   encapsulated.
+
+   In order to support an adequately balanced load distribution across
+   multiple links, IP header information must be used.  Common practice
+   today is to reinspect the IP headers at each LSR and use the label
+   stack and IP header information in a hash performed at each LSR.
+   Further details are provided in Section 2.4.5.
+
+   The use of this technique is so ubiquitous in provider networks that
+   lack of support for multipath makes any product unsuitable for use in
+   large core networks.  This will continue to be the case in the near
+   future, even as deployment of the MPLS Entropy Label begins to relax
+   the core LSR multipath performance requirements given the existing
+   deployed base of edge equipment without the ability to add an Entropy
+   Label.
+
+   A generation of edge equipment supporting the ability to add an MPLS
+   Entropy Label is needed before the performance requirements for core
+   LSRs can be relaxed.  However, it is likely that two generations of
+   deployment in the future will allow core LSRs to support full packet
+   rate only when a relatively small number of MPLS labels need to be
+   inspected before hashing.  For now, don't count on it.
+
+   Common practice today is to reinspect the packet at each LSR and use
+   information from the packet combined with a hash seed that is
+   selected by each LSR.  Where Flow Labels or Entropy Labels are used,
+   a hash seed must be used when creating these labels.
+
+
+
+
+Villamizar, et al.            Informational                    [Page 23]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+2.4.1.  Pseudowire Control Word
+
+   Within the core of a network, some form of multipath is almost
+   certain to be used.  Multipath techniques deployed today are likely
+   to be looking beneath the label stack for an opportunity to hash on
+   IP addresses.
+
+   A pseudowire encapsulated at a network edge must have a means to
+   prevent reordering within the core if the pseudowire will be crossing
+   a network core, or any part of a network topology where multipath is
+   used (see [RFC4385] and [RFC4928]).
+
+   Not supporting the ability to encapsulate a pseudowire with a Control
+   Word may lock a product out from consideration.  A pseudowire
+   capability without Control Word support might be sufficient for
+   applications that are strictly both intra-metro and low bandwidth.
+   However, a provider with other applications will very likely not
+   tolerate having equipment that can only support a subset of their
+   pseudowire needs.
+
+2.4.2.  Large Microflows
+
+   Where multipath makes use of a simple hash and simple load balance
+   such as modulo or other fixed allocation (see Section 2.4), there can
+   be the presence of large microflows that each consume 10% of the
+   capacity of a component link of a potentially congested composite
+   link.  One such microflow can upset the traffic balance, and more
+   than one can reduce the effective capacity of the entire composite
+   link by more than 10%.
+
+   When even a very small number of large microflows are present, there
+   is a significant probability that more than one of these large
+   microflows could fall on the same component link.  If the traffic
+   contribution from large microflows is small, the probability for
+   three or more large microflows on the same component link drops
+   significantly.  Therefore, in a network where a significant number of
+   parallel 10 Gb/s links exists, even a 1 Gb/s pseudowire or other
+   large microflow that could not otherwise be subdivided into smaller
+   flows should carry a Flow Label or Entropy Label if possible.
+
+   Active management of the hash space to better accommodate large
+   microflows has been implemented and deployed in the past; however,
+   such techniques are out of scope for this document.
+
+
+
+
+
+
+
+
+Villamizar, et al.            Informational                    [Page 24]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+2.4.3.  Pseudowire Flow Label
+
+   Unlike a pseudowire Control Word, a pseudowire Flow Label [RFC6391]
+   is required only for pseudowires that have a relatively large
+   capacity.  There are many cases where a pseudowire Flow Label makes
+   sense.  Any service such as a VPN that carries IP traffic within a
+   pseudowire can make use of a pseudowire Flow Label.
+
+   Any pseudowire carried over MPLS that makes use of the pseudowire
+   Control Word and does not carry a Flow Label is in effect a single
+   microflow (in the terms defined in [RFC2475]) and may result in the
+   types of problems described in Section 2.4.2.
+
+2.4.4.  MPLS Entropy Label
+
+   The MPLS Entropy Label simplifies flow group identification [RFC6790]
+   at midpoint LSRs.  Prior to the MPLS Entropy Label, midpoint LSRs
+   needed to inspect the entire label stack and often the IP headers to
+   provide an adequate distribution of traffic when using multipath
+   techniques (see Section 2.4.5).  With the use of the MPLS Entropy
+   Label, a hash can be performed closer to network edges, placed in the
+   label stack, and used by midpoint LSRs without fully reinspecting the
+   label stack and inspecting the payload.
+
+   The MPLS Entropy Label is capable of avoiding full label stack and
+   payload inspection within the core where performance levels are most
+   difficult to achieve (see Section 2.3).  The label stack inspection
+   can be terminated as soon as the first Entropy Label is encountered,
+   which is generally after a small number of labels are inspected.
+
+   In order to provide these benefits in the core, an LSR closer to the
+   edge must be capable of adding an Entropy Label.  This support may
+   not be required in the access tier, the tier closest to the customer,
+   but is likely to be required in the edge or the border to the network
+   core.  An LSR peering with external networks will also need to be
+   able to add an Entropy Label on incoming traffic.
+
+2.4.5.  Fields Used for Multipath Load Balance
+
+   The most common multipath techniques are based on a hash over a set
+   of fields.  Regardless of whether a hash is used or some other method
+   is used, there is a limited set of fields that can safely be used for
+   multipath.
+
+
+
+
+
+
+
+
+Villamizar, et al.            Informational                    [Page 25]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+2.4.5.1.  MPLS Fields in Multipath
+
+   If the "outer" or "first" layer of encapsulation is MPLS, then label
+   stack entries are used in the hash.  Within a finite amount of time
+   (and for small packets arriving at high speed, that time can be quite
+   limited), only a finite number of label entries can be inspected.
+   Pipelined or parallel architectures improve this, but the limit is
+   still finite.
+
+   The following guidelines are provided for use of MPLS fields in
+   multipath load balancing.
+
+   1.  Only the 20-bit label field SHOULD be used.  The TTL field SHOULD
+       NOT be used.  The S bit MUST NOT be used.  The TC field (formerly
+       EXP) MUST NOT be used.  See text following this list for reasons.
+
+   2.  If an ELI label is found, then if the LSR supports Entropy
+       Labels, the EL label field in the next label entry (the EL)
+       SHOULD be used, label entries below that label SHOULD NOT be
+       used, and the MPLS payload SHOULD NOT be used.  See below this
+       list for reasons.
+
+   3.  Special-purpose labels (label values 0-15) MUST NOT be used.
+       Extended special-purpose labels (any label following label 15)
+       MUST NOT be used.  In particular, GAL and RA MUST NOT be used so
+       that OAM traffic follows the same path as payload packets with
+       the same label stack.
+
+   4.  If a new special-purpose label or extended special-purpose label
+       is defined that requires special load-balance processing, then,
+       as is the case for the ELI label, a special action may be needed
+       rather than skipping the special-purpose label or extended
+       special-purpose label.
+
+   5.  The most entropy is generally found in the label stack entries
+       near the bottom of the label stack (innermost label, closest to
+       S=1 bit).  If the entire label stack cannot be used (or entire
+       stack up to an EL), then it is better to use as many labels as
+       possible closest to the bottom of stack.
+
+   6.  If no ELI is encountered, and the first nibble of payload
+       contains a 4 (IPv4) or 6 (IPv6), an implementation SHOULD support
+       the ability to interpret the payload as IPv4 or IPv6 and extract
+       and use appropriate fields from the IP headers.  This feature is
+       considered a nonnegotiable requirement by many service providers.
+       If supported, there MUST be a way to disable it (if, for example,
+       PW without CW are used).  This ability to disable this feature is
+       considered a nonnegotiable requirement by many service providers.
+
+
+
+Villamizar, et al.            Informational                    [Page 26]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+       Therefore, an implementation has a very strong incentive to
+       support both options.
+
+   7.  A label that is popped at egress (UHP pop) SHOULD NOT be used.  A
+       label that is popped at the penultimate hop (PHP pop) SHOULD be
+       used.
+
+   Apparently, some chips have made use of the TC (formerly EXP) bits as
+   a source of entropy.  This is very harmful since it will reorder
+   Assured Forwarding (AF) traffic [RFC2597] when a subset does not
+   conform to the configured rates and is remarked but not dropped at a
+   prior LSR.  Traffic that uses MPLS ECN [RFC5129] can also be
+   reordered if TC is used for entropy.  Therefore, as stated in the
+   guidelines above, the TC field (formerly EXP) MUST NOT be used in
+   multipath load balancing as it violates Differentiated Services
+   Ordered Aggregate (OA) requirements in these two instances.
+
+   Use of the MPLS label entry S bit would result in putting OAM traffic
+   on a different path if the addition of a GAL at the bottom of stack
+   removed the S bit from the prior label.
+
+   If an ELI label is found, then if the LSR supports Entropy Labels,
+   the EL label field in the next label entry (the EL) SHOULD be used,
+   and the search for additional entropy within the packet SHOULD be
+   terminated.  Failure to terminate the search will impact client MPLS-
+   TP LSPs carried within server MPLS LSPs.  A network operator has the
+   option to use administrative attributes as a means to identify LSRs
+   that do not terminate the entropy search at the first EL.
+   Administrative attributes are defined in [RFC3209].  Some
+   configuration is required to support this.
+
+   If the label removed by a PHP pop is not used, then for any PW for
+   which CW is used, there is no basis for multipath load split.  In
+   some networks, it is infeasible to put all PW traffic on one
+   component link.  Any PW that does not use CW will be improperly
+   split, regardless of whether the label removed by a PHP pop is used.
+   Therefore, the PHP pop label SHOULD be used as recommended above.
+
+2.4.5.2.  IP Fields in Multipath
+
+   Inspecting the IP payload provides the most entropy in provider
+   networks.  The practice of looking past the bottom of stack label for
+   an IP payload is well accepted and documented in [RFC4928] and in
+   other RFCs.
+
+   Where IP is mentioned in the document, both IPv4 and IPv6 apply.  All
+   LSRs MUST fully support IPv6.
+
+
+
+
+Villamizar, et al.            Informational                    [Page 27]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+   When information in the IP header is used, the following guidelines
+   apply:
+
+   1.  Both the IP source address and IP destination address SHOULD be
+       used.  There MAY be an option to reverse the order of these
+       addresses, improving the ability to provide symmetric paths in
+       some cases.  Many service providers require that both addresses
+       be used.
+
+   2.  Implementations SHOULD allow inspection of the IP protocol field
+       and use of the UDP or TCP port numbers.  For many service
+       providers, this feature is considered mandatory, particularly for
+       enterprise, data center, or edge equipment.  If this feature is
+       provided, it SHOULD be possible to disable use of TCP and UDP
+       ports.  Many service providers consider it a nonnegotiable
+       requirement that use of UDP and TCP ports can be disabled.
+       Therefore, there is a strong incentive for implementations to
+       provide both options.
+
+   3.  Equipment suppliers MUST NOT make assumptions that because the IP
+       version field is equal to 4 (an IPv4 packet) that the IP protocol
+       will either be TCP (IP protocol 6) or UDP (IP protocol 17) and
+       blindly fetch the data at the offset where the TCP or UDP ports
+       would be found.  With IPv6, TCP and UDP port numbers are not at
+       fixed offsets.  With IPv4 packets carrying IP options, TCP and
+       UDP port numbers are not at fixed offsets.
+
+   4.  The IPv6 header flow field SHOULD be used.  This is the explicit
+       purpose of the IPv6 flow field; however, observed flow fields
+       rarely contain a non-zero value.  Some uses of the flow field
+       have been defined, such as [RFC6438].  In the absence of MPLS
+       encapsulation, the IPv6 flow field can serve a role equivalent to
+       the Entropy Label.
+
+   5.  Support for other protocols that share a common Layer 4 header
+       such as RTP [RFC3550], UDP-Lite [RFC3828], SCTP [RFC4960], and
+       DCCP [RFC4340] SHOULD be provided, particularly for edge or
+       access equipment where additional entropy may be needed.
+       Equipment SHOULD also use RTP, UDP-lite, SCTP, and DCCP headers
+       when creating an Entropy Label.
+
+   6.  The following IP header fields should not or must not be used:
+
+       A.  Similar to avoiding TC in MPLS, the IP DSCP, and ECN bits
+           MUST NOT be used.
+
+       B.  The IPv4 TTL or IPv6 Hop Count SHOULD NOT be used.
+
+
+
+
+Villamizar, et al.            Informational                    [Page 28]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+       C.  Note that the IP TOS field was deprecated.  ([RFC0791] was
+           updated by [RFC2474].)  No part of the IP DSCP field can be
+           used (formerly IP PREC and IP TOS bits).
+
+   7.  Some IP encapsulations support tunneling, such as IP-in-IP, GRE,
+       L2TPv3, and IPsec.  These provide a greater source of entropy
+       that some provider networks carrying large amounts of tunneled
+       traffic may need, for example, as used in [RFC5640] for GRE and
+       L2TPv3.  The use of tunneling header information is out of scope
+       for this document.
+
+   This document makes the following recommendations.  These
+   recommendations are not required to claim compliance to any existing
+   RFC; therefore, implementers are free to ignore them, but due to
+   service provider requirements should consider the risk of doing so.
+   The use of IP addresses MUST be supported, and TCP and UDP ports
+   (conditional on the protocol field and properly located) MUST be
+   supported.  The ability to disable use of UDP and TCP ports MUST be
+   available.
+
+   Though potentially very useful in some networks, it is uncommon to
+   support using payloads of tunneling protocols carried over IP.
+   Though the use of tunneling protocol header information is out of
+   scope for this document, it is not discouraged.
+
+2.4.5.3.  Fields Used in Flow Label
+
+   The ingress to a pseudowire (PW) can extract information from the
+   payload being encapsulated to create a Flow Label.  [RFC6391]
+   references IP carried in Ethernet as an example.  The Native Service
+   Processing (NSP) function defined in [RFC3985] differs with
+   pseudowire type.  It is in the NSP function where information for a
+   specific type of PW can be extracted for use in a Flow Label.
+   Determining which fields to use for any given PW NSP is out of scope
+   for this document.
+
+2.4.5.4.  Fields Used in Entropy Label
+
+   An Entropy Label is added at the ingress to an LSP.  The payload
+   being encapsulated is most often MPLS, a PW, or IP.  The payload type
+   is identified by the Layer 2 encapsulation (Ethernet, GFP, POS,
+   etc.).
+
+   If the payload is MPLS, then the information used to create an
+   Entropy Label is the same information used for local load balancing
+   (see Section 2.4.5.1).  This information MUST be extracted for use in
+   generating an Entropy Label even if the LSR local egress interface is
+   not a multipath.
+
+
+
+Villamizar, et al.            Informational                    [Page 29]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+   Of the non-MPLS payload types, only payloads that are forwarded are
+   of interest.  For example, payloads using the Address Resolution
+   Protocol (ARP) are not forwarded, and payloads using the
+   Connectionless-mode Network Protocol (CLNP), which is used only for
+   IS-IS, are not forwarded.
+
+   The non-MPLS payload types of greatest interest are IPv4 and IPv6.
+   The guidelines in Section 2.4.5.2 apply to fields used to create an
+   Entropy Label.
+
+   The IP tunneling protocols mentioned in Section 2.4.5.2 may be more
+   applicable to generation of an Entropy Label at the edge or access
+   where deep packet inspection is practical due to lower interface
+   speeds than in the core where deep packet inspection may be
+   impractical.
+
+2.5.  MPLS-TP and UHP
+
+   MPLS-TP introduces forwarding demands that will be extremely
+   difficult to meet in a core network.  Most troublesome is the
+   requirement for Ultimate Hop Popping (UHP), the opposite of
+   Penultimate Hop Popping (PHP).  Using UHP opens the possibility of
+   one or more MPLS pop operations plus an MPLS swap operation for each
+   packet.  The potential for multiple lookups and multiple counter
+   instances per packet exists.
+
+   As networks grow and tunneling of LDP LSPs into RSVP-TE LSPs is used,
+   and/or RSVP-TE hierarchy is used, the requirement to perform one or
+   more MPLS pop operations plus an MPLS swap operation (and possibly a
+   push or two) increases.  If MPLS-TP LM (link monitoring) OAM is
+   enabled at each layer, then a packet and byte count MUST be
+   maintained for each pop and swap operation so as to offer OAM for
+   each layer.
+
+2.6.  Local Delivery of Packets
+
+   There are a number of situations in which packets are destined to a
+   local address or where a return packet must be generated.  There is a
+   need to mitigate the potential for outage as a result of either
+   attacks on network infrastructure, or in some cases unintentional
+   misconfiguration resulting in processor overload.  Some hardware
+   assistance is needed for all traffic destined to the general-purpose
+   CPU that is used in processing of the MPLS control protocol or the
+   network management protocol and in most cases to other general-
+   purpose CPUs residing on an LSR.  This is due to the ease of
+   overwhelming such a processor with traffic arriving on LSR high-speed
+   interfaces, whether the traffic is malicious or not.
+
+
+
+
+Villamizar, et al.            Informational                    [Page 30]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+   Denial of service (DoS) protection is an area requiring hardware
+   support that is often overlooked or inadequately considered.
+   Hardware assists are also needed for OAM, particularly the more
+   demanding MPLS-TP OAM.
+
+2.6.1.  DoS Protection
+
+   Modern equipment supports a number of control-plane and management-
+   plane protocols.  Generally, no single means of protecting network
+   equipment from DoS attacks is sufficient, particularly for high-speed
+   interfaces.  This problem is not specific to MPLS but is a topic that
+   cannot be ignored when implementing or evaluating MPLS
+   implementations.
+
+   Two types of protections are often cited as the primary means of
+   protecting against attacks of all kinds.
+
+   Isolated Control/Management Traffic
+       Control and management traffic can be carried out-of-band (OOB),
+       meaning not intermixed with payload.  For MPLS, use of G-ACh and
+       GAL to carry control and management traffic provides a means of
+       isolation from potentially malicious payloads.  Used alone, the
+       compromise of a single node, including a small computer at a
+       network operations center, could compromise an entire network.
+       Implementations that send all G-ACh/GAL traffic directly to a
+       routing engine CPU are subject to DoS attack as a result of such
+       a compromise.
+
+   Cryptographic Authentication
+       Cryptographic authentication can very effectively prevent
+       malicious injection of control or management traffic.
+       Cryptographic authentication can in some circumstances be subject
+       to DoS attack by overwhelming the capacity of the decryption with
+       a high volume of malicious traffic.  For very-low-speed
+       interfaces, cryptographic authentication can be performed by the
+       general-purpose CPU used as a routing engine.  For all other
+       cases, cryptographic hardware may be needed.  For very-high-speed
+       interfaces, even cryptographic hardware can be overwhelmed.
+
+   Some control and management protocols are often carried with payload
+   traffic.  This is commonly the case with BGP, T-LDP, and SNMP.  It is
+   often the case with RSVP-TE.  Even when carried over G-ACh/GAL,
+   additional measures can reduce the potential for a minor breach to be
+   leveraged to a full network attack.
+
+   Some of the additional protections are supported by hardware packet
+   filtering.
+
+
+
+
+Villamizar, et al.            Informational                    [Page 31]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+   GTSM
+       [RFC5082] defines a mechanism that uses the IPv4 TTL or IPv6 Hop
+       Limit fields to ensure control traffic that can only originate
+       from an immediate neighbor is not forged and is not originating
+       from a distant source.  GTSM can be applied to many control
+       protocols that are routable, for example, LDP [RFC6720].
+
+   IP Filtering
+       At the very minimum, packet filtering plus classification and use
+       of multiple queues supporting rate limiting is needed for traffic
+       that could potentially be sent to a general-purpose CPU used as a
+       routing engine.  The first level of filtering only allows
+       connections to be initiated from specific IP prefixes to specific
+       destination ports and then preferably passes traffic directly to
+       a cryptographic engine and/or rate limits.  The second level of
+       filtering passes connected traffic, such as TCP connections
+       having received at least one authenticated SYN or having been
+       locally initiated.  The second level of filtering only passes
+       traffic to specific address and port pairs to be checked for
+       cryptographic authentication.
+
+   The cryptographic authentication is generally the last resort in DoS
+   attack mitigation.  If a packet must be first sent to a general-
+   purpose CPU, then sent to a cryptographic engine, a DoS attack is
+   possible on high-speed interfaces.  Only where hardware can fully
+   process a cryptographic authentication without intervention from a
+   general-purpose CPU (to find the authentication field and to identify
+   the portion of packet to run the cryptographic algorithm over) is
+   cryptographic authentication beneficial in protecting against DoS
+   attacks.
+
+   For chips supporting multiple 100 Gb/s interfaces, only a very large
+   number of parallel cryptographic engines can provide the processing
+   capacity to handle a large-scale DoS or distributed DoS (DDoS)
+   attack.  For many forwarding chips, this much processing power
+   requires significant chip real estate and power, and therefore
+   reduces system space and power density.  For this reason,
+   cryptographic authentication is not considered a viable first line of
+   defense.
+
+   For some networks, the first line of defense is some means of
+   supporting OOB control and management traffic.  In the past, this OOB
+   channel might make use of overhead bits in SONET or OTN or a
+   dedicated DWDM wavelength.  G-ACh and GAL provide an alternative OOB
+   mechanism that is independent of underlying layers.  In other
+   networks, including most IP/MPLS networks, perimeter filtering serves
+   a similar purpose, though it is less effective without extreme
+   vigilance.
+
+
+
+Villamizar, et al.            Informational                    [Page 32]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+   A second line of defense is filtering, including GTSM.  For protocols
+   such as EBGP, GTSM and other filtering are often the first line of
+   defense.  Cryptographic authentication is usually the last line of
+   defense and insufficient by itself to mitigate DoS or DDoS attacks.
+
+2.6.2.  MPLS OAM
+
+   [RFC4377] defines requirements for MPLS OAM that predate MPLS-TP.
+   [RFC4379] defines what is commonly referred to as LSP Ping and LSP
+   Traceroute.  [RFC4379] is updated by [RFC6424], which supports MPLS
+   tunnels and stitched LSP and P2MP LSP.  [RFC4379] is updated by
+   [RFC6425], which supports P2MP LSP.  [RFC4379] is updated by
+   [RFC6426] to support MPLS-TP connectivity verification (CV) and route
+   tracing.
+
+   [RFC4950] extends the ICMP format to support TTL expiration that may
+   occur when using IP Traceroute within an MPLS tunnel.  The ICMP
+   message generation can be implemented in forwarding hardware, but if
+   the ICMP packets are sent to a general-purpose CPU, this packet flow
+   must be rate limited to avoid a potential DoS attack.
+
+   [RFC5880] defines Bidirectional Forwarding Detection (BFD), a
+   protocol intended to detect faults in the bidirectional path between
+   two forwarding engines.  [RFC5884] and [RFC5885] define BFD for MPLS.
+   BFD can provide failure detection on any kind of path between
+   systems, including direct physical links, virtual circuits, tunnels,
+   MPLS Label Switched Paths (LSPs), multihop routed paths, and
+   unidirectional links as long as there is some return path.
+
+   The processing requirements for BFD are less than for LSP Ping,
+   making BFD somewhat better suited for relatively high-rate proactive
+   monitoring.  BFD does not verify that the data plane matches the
+   control plane, where LSP Ping does.  LSP Ping is somewhat better
+   suited for on-demand monitoring including relatively low-rate
+   periodic verification of the data plane and as a diagnostic tool.
+
+   Hardware assistance is often provided for BFD response where BFD
+   setup or parameter change is not involved and may be necessary for
+   relatively high-rate proactive monitoring.  If both BFD and LSP Ping
+   are recognized in filtering prior to passing traffic to a general-
+   purpose CPU, appropriate DoS protection can be applied (see
+   Section 2.6.1).  Failure to recognize BFD and LSP Ping and at least
+   to rate limit creates the potential for misconfiguration to cause
+   outages rather than cause errors in the misconfigured OAM.
+
+
+
+
+
+
+
+Villamizar, et al.            Informational                    [Page 33]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+2.6.3.  Pseudowire OAM
+
+   Pseudowire OAM makes use of the control channel provided by Virtual
+   Circuit Connectivity Verification (VCCV) [RFC5085].  VCCV makes use
+   of the pseudowire Control Word.  BFD support over VCCV is defined by
+   [RFC5885].  [RFC5885] is updated by [RFC6478] in support of static
+   pseudowires.  [RFC4379] is updated by [RFC6829] to support LSP Ping
+   for Pseudowire FEC advertised over IPv6.
+
+   G-ACh/GAL (defined in [RFC5586]) is the preferred MPLS-TP OAM control
+   channel and applies to any MPLS-TP endpoints, including pseudowire.
+   See Section 2.6.4 for an overview of MPLS-TP OAM.
+
+2.6.4.  MPLS-TP OAM
+
+   [RFC6669] summarizes the MPLS-TP OAM toolset, the set of protocols
+   supporting the MPLS-TP OAM requirements specified in [RFC5860] and
+   supported by the MPLS-TP OAM framework defined in [RFC6371].
+
+   The MPLS-TP OAM toolset includes:
+
+   CC-CV
+       [RFC6428] defines BFD extensions to support proactive Continuity
+       Check and Connectivity Verification (CC-CV) applications.
+       [RFC6426] provides LSP Ping extensions that are used to implement
+       on-demand connectivity verification.
+
+   RDI
+       Remote Defect Indication (RDI) is triggered by failure of
+       proactive CC-CV, which is BFD based.  For fast RDI, RDI SHOULD be
+       initiated and handled by hardware if BFD is handled in forwarding
+       hardware.  [RFC6428] provides an extension for BFD that includes
+       the RDI in the BFD format and a specification of how this
+       indication is to be used.
+
+   Route Tracing
+       [RFC6426] specifies that the LSP Ping enhancements for MPLS-TP
+       on-demand connectivity verification include information on the
+       use of LSP Ping for route tracing of an MPLS-TP path.
+
+   Alarm Reporting
+       [RFC6427] describes the details of a new protocol supporting
+       Alarm Indication Signal (AIS), Link Down Indication (LDI), and
+       fault management.  Failure to support this functionality in
+       forwarding hardware can potentially result in failure to meet
+       protection recovery time requirements; therefore, support of this
+       functionality is strongly recommended.
+
+
+
+
+Villamizar, et al.            Informational                    [Page 34]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+   Lock Instruct
+       Lock instruct is initiated on demand and therefore need not be
+       implemented in forwarding hardware.  [RFC6435] defines a lock
+       instruct protocol.
+
+   Lock Reporting
+       [RFC6427] covers lock reporting.  Lock reporting need not be
+       implemented in forwarding hardware.
+
+   Diagnostic
+       [RFC6435] defines protocol support for loopback.  Loopback
+       initiation is on demand and therefore need not be implemented in
+       forwarding hardware.  Loopback of packet traffic SHOULD be
+       implemented in forwarding hardware on high-speed interfaces.
+
+   Packet Loss and Delay Measurement
+       [RFC6374] and [RFC6375] define a protocol and profile for Packet
+       Loss Measurement (LM) and Delay Measurement (DM).  LM requires a
+       very accurate capture and insertion of packet and byte counters
+       when a packet is transmitted and capture of packet and byte
+       counters when a packet is received.  This capture and insertion
+       MUST be implemented in forwarding hardware for LM OAM if high
+       accuracy is needed.  DM requires very accurate capture and
+       insertion of a timestamp on transmission and capture of timestamp
+       when a packet is received.  This timestamp capture and insertion
+       MUST be implemented in forwarding hardware for DM OAM if high
+       accuracy is needed.
+
+   See Section 2.6.2 for discussion of hardware support necessary for
+   BFD and LSP Ping.
+
+   CC-CV and alarm reporting is tied to protection and therefore SHOULD
+   be supported in forwarding hardware in order to provide protection
+   for a large number of affected LSPs within target response intervals.
+   When using MPLS-TP, since CC-CV is supported by BFD, providing
+   hardware assistance for BFD processing helps ensure that protection
+   recovery time requirements can be met even for faults affecting a
+   large number of LSPs.
+
+   MPLS-TP Protection State Coordination (PSC) is defined by [RFC6378]
+   and updated by [RFC7324], which corrects some errors in [RFC6378].
+
+2.6.5.  MPLS OAM and Layer 2 OAM Interworking
+
+   [RFC6670] provides the reasons for selecting a single MPLS-TP OAM
+   solution and examines the consequences were ITU-T to develop a second
+   OAM solution that is based on Ethernet encodings and mechanisms.
+
+
+
+
+Villamizar, et al.            Informational                    [Page 35]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+   [RFC6310] and [RFC7023] specify the mapping of defect states between
+   many types of hardware Attachment Circuits (ACs) and associated
+   pseudowires (PWs).  This functionality SHOULD be supported in
+   forwarding hardware.
+
+   It is beneficial if an MPLS OAM implementation can interwork with the
+   underlying server layer and provide a means to interwork with a
+   client layer.  For example, [RFC6427] specifies an inter-layer
+   propagation of AIS and LDI from MPLS server layer to client MPLS
+   layers.  Where the server layer uses a Layer 2 mechanism, such as
+   Ethernet, PPP over SONET/SDH, or GFP over OTN, interwork among layers
+   is also beneficial.  For high-speed interfaces, supporting this
+   interworking in forwarding hardware helps ensure that protection
+   based on this interworking can meet recovery time requirements even
+   for faults affecting a large number of LSPs.
+
+2.6.6.  Extent of OAM Support by Hardware
+
+   Where certain requirements must be met, such as relatively high CC-CV
+   rates and a large number of interfaces, or strict protection recovery
+   time requirements and a moderate number of affected LSPs, some OAM
+   functionality must be supported by forwarding hardware.  In other
+   cases, such as highly accurate LM and DM OAM or strict protection
+   recovery time requirements with a large number of affected LSPs, OAM
+   functionality must be entirely implemented in forwarding hardware.
+
+   Where possible, implementation in forwarding hardware should be in
+   programmable hardware such that if standards are later changed or
+   extended these changes are likely to be accommodated with hardware
+   reprogramming rather than replacement.
+
+   For some functionality, there is a strong case for an implementation
+   in dedicated forwarding hardware.  Examples include packet and byte
+   counters needed for LM OAM as well as needed for management
+   protocols.  Similarly, the capture and insertion of packet and byte
+   counts or timestamps needed for transmitted LM or DM or time
+   synchronization packets MUST be implemented in forwarding hardware if
+   high accuracy is required.
+
+   For some functions, there is a strong case to provide limited support
+   in forwarding hardware, but an external general-purpose processor may
+   be used if performance criteria can be met.  For example, origination
+   of RDI triggered by CC-CV, response to RDI, and Protection State
+   Coordination (PSC) functionality may be supported by hardware, but
+   expansion to a large number of client LSPs and transmission of AIS or
+   RDI to the client LSPs may occur in a general-purpose processor.
+   Some forwarding hardware supports one or more on-chip general-purpose
+   processors that may be well suited for such a role.  [RFC7324], being
+
+
+
+Villamizar, et al.            Informational                    [Page 36]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+   a very recent document that affects a protection state machine that
+   requires hardware support, underscores the importance of having a
+   degree of programmability in forwarding hardware.
+
+   The customer (system supplier or provider) should not dictate design,
+   but should independently validate target functionality and
+   performance.  However, it is not uncommon for service providers and
+   system implementers to insist on reviewing design details (under a
+   non-disclosure agreement) due to past experiences with suppliers and
+   to reject suppliers who are unwilling to provide details.
+
+2.6.7.  Support for IPFIX in Hardware
+
+   The IPFIX architecture is defined by [RFC5470].  IPFIX supports per-
+   flow statistics.  IPFIX information elements (IEs) are defined in
+   [RFC7012] and include IEs for MPLS.
+
+   The forwarding chips used in core routers are not optimized for high-
+   touch applications like IPFIX.  Often, support for IPFIX in core
+   routers is limited to optional IPFIX metering, which involves a
+   1-in-N packet sampling, limited filtering support, and redirection to
+   either an internal CPU or an external interface.  The CPU or device
+   at the other end of the external interface then implements the full
+   IPFIX filtering and IPFIX collector functionality.
+
+   LSRs that are intended to be deployed further from the core may
+   support lower-capacity interfaces but support higher-touch
+   applications on the forwarding hardware and may provide dedicated
+   hardware to support a greater subset of IPFIX functionality before
+   handing off to a general-purpose CPU.  In some cases, far from the
+   core the entire IPFIX functionality up to and including the collector
+   may be implemented in hardware and firmware in the forwarding
+   silicon.  It is also worth noting that at lower speeds a general-
+   purpose CPU may become adequate to implement IPFIX, particularly if
+   metering is used.
+
+2.7.  Number and Size of Flows
+
+   Service provider networks may carry up to hundreds of millions of
+   flows on 10 Gb/s links.  Most flows are very short lived, many under
+   a second.  A subset of the flows are low capacity and somewhat long
+   lived.  When Internet traffic dominates capacity, a very small subset
+   of flows are high capacity and/or very long lived.
+
+
+
+
+
+
+
+
+Villamizar, et al.            Informational                    [Page 37]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+   Two types of limitations with regard to number and size of flows have
+   been observed.
+
+   1.  Some hardware cannot handle some high-capacity flows because of
+       internal paths that are limited, such as per-packet backplane
+       paths or paths internal or external to chips such as buffer
+       memory paths.  Such designs can handle aggregates of smaller
+       flows.  Some hardware with acknowledged limitations has been
+       successfully deployed but may be increasingly problematic if the
+       capacity of large microflows in deployed networks continues to
+       grow.
+
+   2.  Some hardware approaches cannot handle a large number of flows,
+       or a large number of large flows, due to attempting to count per
+       flow, rather than deal with aggregates of flows.  Hash techniques
+       scale with regard to number of flows due to a fixed hash size
+       with many flows falling into the same hash bucket.  Techniques
+       that identify individual flows have been implemented but have
+       never successfully deployed for Internet traffic.
+
+3.  Questions for Suppliers
+
+   The following questions should be asked of a supplier.  These
+   questions are grouped into broad categories and are intended to be
+   open-ended questions to the supplier.  The tests in Section 4 are
+   intended to verify whether the supplier disclosed any compliance or
+   performance limitations completely and accurately.
+
+3.1.  Basic Compliance
+
+   Q#1   Can the implementation forward packets with an arbitrarily
+         large stack depth?  What limitations exist, and under what
+         circumstances do further limitations come into play (such as
+         high packet rate or specific features enabled or specific types
+         of packet processing)?  See Section 2.1.
+
+   Q#2   Is the entire set of basic MPLS functionality described in
+         Section 2.1 supported?
+
+   Q#3   Is the set of MPLS special-purpose labels handled correctly and
+         with adequate performance?  Are extended special-purpose labels
+         handled correctly and with adequate performance?  See
+         Section 2.1.1.
+
+   Q#4   Are mappings of label value and TC to PHB handled correctly,
+         including L-LSP mappings (RFC 3270) and CT mappings (RFC 4124)
+         to PHB?  See Section 2.1.2.
+
+
+
+
+Villamizar, et al.            Informational                    [Page 38]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+   Q#5   Is time synchronization adequately supported in forwarding
+         hardware?
+
+         A.  Are both PTP and NTP formats supported?
+
+         B.  Is the accuracy of timestamp insertion and incoming
+             stamping sufficient?
+
+         See Section 2.1.3.
+
+   Q#6   Is link bundling supported?
+
+         A.  Can an LSP be pinned to specific components?
+
+         B.  Is the "all-ones" component link supported?
+
+         See Section 2.1.5.
+
+   Q#7   Is MPLS hierarchy supported?
+
+         A.  Are both PHP and UHP supported?  What limitations exist on
+             the number of pop operations with UHP?
+
+         B.  Are the pipe, short-pipe, and uniform models supported?
+             Are TTL and TC values updated correctly at egress where
+             applicable?
+
+         See Section 2.1.6 regarding MPLS hierarchy.  See [RFC3443]
+         regarding PHP, UHP, and pipe, short-pipe, and uniform models.
+
+   Q#8   Is FRR supported?
+
+         A.  Are both "One-to-One Backup" and "Facility Backup"
+             supported?
+
+         B.  What forms of IP/LDP FRR are supported?
+
+         C.  How quickly does protection recovery occur?
+
+         D.  Does protection recovery speed increase when a fault
+             affects a large number of protected LSPs?  And if so, by
+             how much?
+
+         See Section 2.1.7.
+
+   Q#9   Are pseudowire Sequence Numbers handled correctly?  See
+         Section 2.1.8.1.
+
+
+
+
+Villamizar, et al.            Informational                    [Page 39]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+   Q#10  Is VPN LER functionality handled correctly and without
+         performance issues?  See Section 2.1.9.
+
+   Q#11  Is MPLS multicast (P2MP and MP2MP) handled correctly?
+
+         A.  Are packets dropped on uncongested outputs if some outputs
+             are congested?
+
+         B.  Is performance limited in high-fanout situations?
+
+         See Section 2.2.
+
+3.2.  Basic Performance
+
+   Q#12 Can very small packets be forwarded at full line rate on all
+        interfaces indefinitely?  What limitations exist?  And under
+        what circumstances do further limitations come into play (such
+        as specific features enabled or specific types of packet
+        processing)?
+
+   Q#13 Customers must decide whether to relax the prior requirement and
+        to what extent.  If the answer to the prior question indicates
+        that limitations exist, then:
+
+        A.  What is the smallest packet size where full line rate
+            forwarding can be supported?
+
+        B.  What is the longest burst of full-rate small packets that
+            can be supported?
+
+        Specify circumstances (such as specific features enabled or
+        specific types of packet processing) that often impact these
+        rates and burst sizes.
+
+   Q#14 How many pop operations can be supported along with a swap
+        operation at full line rate while maintaining per-LSP packet and
+        byte counts for each pop and swap?  This requirement is
+        particularly relevant for MPLS-TP.
+
+   Q#15 How many label push operations can be supported.  While this
+        limitation is rarely an issue, it applies to both PHP and UHP,
+        unlike the pop limit that applies to UHP.
+
+   Q#16 For a worst case where all packets arrive on one LSP, what is
+        the counter overflow time?  Are any means provided to avoid
+        polling all counters at short intervals?  This applies to both
+        MPLS and MPLS-TP.
+
+
+
+
+Villamizar, et al.            Informational                    [Page 40]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+3.3.  Multipath Capabilities and Performance
+
+   Multipath capabilities and performance do not apply to MPLS-TP, but
+   they apply to MPLS and apply if MPLS-TP is carried in MPLS.
+
+   Q#17 How are large microflows accommodated?  Is there active
+        management of the hash space mapping to output ports?  See
+        Section 2.4.2.
+
+   Q#18 How many MPLS labels can be included in a hash based on the MPLS
+        label stack?
+
+   Q#19 Is packet rate performance decreased beyond some number of
+        labels?
+
+   Q#20 Can the IP header and payload information below the MPLS stack
+        be used in the hash?  If so, which IP fields, payload types, and
+        payload fields are supported?
+
+   Q#21 At what maximum MPLS label stack depth can Bottom of Stack and
+        an IP header appear without impacting packet rate performance?
+
+   Q#22 Are special-purpose labels excluded from the label stack hash?
+        Are extended special-purpose labels excluded from the label
+        stack hash?  See Section 2.4.5.1.
+
+   Q#23 How is multipath performance affected by high-capacity flows, an
+        extremely large number of flows, or very short-lived flows?  See
+        Section 2.7.
+
+3.4.  Pseudowire Capabilities and Performance
+
+   Q#24 Is the pseudowire Control Word supported?
+
+   Q#25 What is the maximum rate of pseudowire encapsulation and
+        decapsulation?  Apply the same questions as in Section 3.2
+        ("Basic Performance") for any packet-based pseudowire, such as
+        IP VPN or Ethernet.
+
+   Q#26 Does inclusion of a pseudowire Control Word impact performance?
+
+   Q#27 Are Flow Labels supported?
+
+   Q#28 If so, what fields are hashed on for the Flow Label for
+        different types of pseudowires?
+
+   Q#29 Does inclusion of a Flow Label impact performance?
+
+
+
+
+Villamizar, et al.            Informational                    [Page 41]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+3.5.  Entropy Label Support and Performance
+
+   Q#30 Can an Entropy Label be added when acting as an ingress LER, and
+        can it be removed when acting as an egress LER?
+
+   Q#31 If an Entropy Label can be added, what fields are hashed on for
+        the Entropy Label?
+
+   Q#32 Does adding or removing an Entropy Label impact packet rate
+        performance?
+
+   Q#33 Can an Entropy Label be detected in the label stack, used in the
+        hash, and properly terminate the search for further information
+        to hash on?
+
+   Q#34 Does using an Entropy Label have any negative impact on
+        performance?  It should have no impact or a positive impact.
+
+3.6.  DoS Protection
+
+   Q#35 For each control- and management-plane protocol in use, what
+        measures are taken to provide DoS attack hardening?
+
+   Q#36 Have DoS attack tests been performed?
+
+   Q#37 Can compromise of an internal computer on a management subnet be
+        leveraged for any form of attack including DoS attack?
+
+3.7.  OAM Capabilities and Performance
+
+   Q#38 What OAM proactive and on-demand mechanisms are supported?
+
+   Q#39 What performance limits exist under high proactive monitoring
+        rates?
+
+   Q#40 Can excessively high proactive monitoring rates impact control-
+        plane performance or cause control-plane instability?
+
+   Q#41 Ask the prior questions for each of the following.
+
+        A.  MPLS OAM
+
+        B.  Pseudowire OAM
+
+        C.  MPLS-TP OAM
+
+
+
+
+
+
+Villamizar, et al.            Informational                    [Page 42]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+        D.  Layer 2 OAM Interworking
+
+        See Section 2.6.
+
+4.  Forwarding Compliance and Performance Testing
+
+   Packet rate performance of equipment supporting a large number of 10
+   Gb/s or 100 Gb/s links is not possible using desktop computers or
+   workstations.  The use of high-end workstations as a source of test
+   traffic was barely viable 20 years ago but is no longer at all
+   viable.  Though custom microcode has been used on specialized router
+   forwarding cards to serve the purpose of generating test traffic and
+   measuring it, for the most part, performance testing will require
+   specialized test equipment.  There are multiple sources of suitable
+   equipment.
+
+   The set of tests listed here do not correspond one-to-one to the set
+   of questions in Section 3.  The same categorization is used, and
+   these tests largely serve to validate answers provided to the prior
+   questions.  They can also provide answers where a supplier is
+   unwilling to disclose compliance or performance.
+
+   Performance testing is the domain of the IETF Benchmark Methodology
+   Working Group (BMWG).  Below are brief descriptions of conformance
+   and performance tests.  Some very basic tests, specified in
+   [RFC5695], partially cover only the basic performance test T#3.
+
+   The following tests should be performed by the systems designer or
+   deployer; or, if it is not practical for the potential customer to
+   perform the tests directly, they may be performed by the supplier on
+   their behalf.  These tests are grouped into broad categories.
+
+   The tests in Section 4.1 should be repeated under various conditions
+   to retest basic performance when critical capabilities are enabled.
+   Complete repetition of the performance tests enabling each capability
+   and combinations of capabilities would be very time intensive;
+   therefore, a reduced set of performance tests can be used to gauge
+   the impact of enabling specific capabilities.
+
+4.1.  Basic Compliance
+
+   T#1  Test forwarding at a high rate for packets with varying number
+        of label entries.  While packets with more than a dozen label
+        entries are unlikely to be used in any practical scenario today,
+        it is useful to know if limitations exists.
+
+
+
+
+
+
+Villamizar, et al.            Informational                    [Page 43]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+   T#2  For each of the questions listed under "Basic Compliance" in
+        Section 3, verify the claimed compliance.  For any functionality
+        considered critical to a deployment, the applicable performance
+        using each capability under load should be verified in addition
+        to basic compliance.
+
+4.2.  Basic Performance
+
+   T#3  Test packet forwarding at full line rate with small packets.
+        See [RFC5695].  The most likely case to fail is the smallest
+        packet size.  Also, test with packet sizes in 4-byte increments
+        ranging from payload sizes of 40 to 128 bytes.
+
+   T#4  If the prior tests did not succeed for all packet sizes, then
+        perform the following tests.
+
+        A.  Increase the packet size by 4 bytes until a size is found
+            that can be forwarded at full rate.
+
+        B.  Inject bursts of consecutive small packets into a stream of
+            larger packets.  Allow some time for recovery between
+            bursts.  Increase the number of packets in the burst until
+            packets are dropped.
+
+   T#5  Send test traffic where a swap operation is required.  Also set
+        up multiple LSPs carried over other LSPs where the device under
+        test (DUT) is the egress of these LSPs.  Create test packets
+        such that the swap operation is performed after pop operations,
+        increasing the number of pop operations until forwarding of
+        small packets at full line rate can no longer be supported.
+        Also, check to see how many pop operations can be supported
+        before the full set of counters can no longer be maintained.
+        This requirement is particularly relevant for MPLS-TP.
+
+   T#6  Send all traffic on one LSP and see if the counters become
+        inaccurate.  Often, counters on silicon are much smaller than
+        the 64-bit packet and byte counters in various IETF MIBs.
+        System developers should consider what counter polling rate is
+        necessary to maintain accurate counters and whether those
+        polling rates are practical.  Relevant MIBs for MPLS are
+        discussed in [RFC4221] and [RFC6639].
+
+   T#7  [RFC6894] provides a good basis for MPLS FRR testing.  Similar
+        testing should be performed to determine restoration times;
+        however, this testing is far more difficult to perform due to
+        the need for a simulated test topology that is capable of
+        simulating the signaling used in restoration.  The simulated
+        topology should be comparable with the target deployment in the
+
+
+
+Villamizar, et al.            Informational                    [Page 44]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+        number of nodes and links and in resource usage flooding and
+        setup delays.  Some commercial test equipment can support this
+        type of testing.
+
+4.3.  Multipath Capabilities and Performance
+
+   Multipath capabilities do not apply to MPLS-TP but apply to MPLS and
+   apply if MPLS-TP is carried in MPLS.
+
+   T#8  Send traffic at a rate well exceeding the capacity of a single
+        multipath component link, and where entropy exists only below
+        the top of stack.  If only the top label is used, this test will
+        fail immediately.
+
+   T#9  Move the labels with entropy down in the stack until either the
+        full forwarding rate can no longer be supported or most or all
+        packets try to use the same component link.
+
+   T#10 Repeat the two tests above with the entropy contained in IP
+        headers or IP payload fields below the label stack rather than
+        in the label stack.  Test with the set of IP headers or IP
+        payload fields considered relevant to the deployment or to the
+        target market.
+
+   T#11 Determine whether traffic that contains a pseudowire Control
+        Word is interpreted as IP traffic.  Information in the payload
+        MUST NOT be used in the load balancing if the first nibble of
+        the packet is not 4 or 6 (IPv4 or IPv6).
+
+   T#12 Determine whether special-purpose labels and extended special-
+        purpose labels are excluded from the label stack hash.  They
+        MUST be excluded.
+
+   T#13 Perform testing in the presence of combinations of:
+
+        A.  Very large microflows.
+
+        B.  Relatively short-lived high-capacity flows.
+
+        C.  Extremely large numbers of flows.
+
+        D.  Very short-lived small flows.
+
+
+
+
+
+
+
+
+
+Villamizar, et al.            Informational                    [Page 45]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+4.4.  Pseudowire Capabilities and Performance
+
+   T#14 Ensure that pseudowire can be set up with a pseudowire label and
+        pseudowire Control Word added at ingress and the pseudowire
+        label and pseudowire Control Word removed at egress.
+
+   T#15 For pseudowire that contains variable-length payload packets,
+        repeat performance tests listed under "Basic Performance" for
+        pseudowire ingress and egress functions.
+
+   T#16 Repeat pseudowire performance tests with and without a
+        pseudowire Control Word.
+
+   T#17 Determine whether pseudowire can be set up with a pseudowire
+        label, Flow Label, and pseudowire Control Word added at ingress
+        and the pseudowire label, Flow Label, and pseudowire Control
+        Word removed at egress.
+
+   T#18 Determine which payload fields are used to create the Flow Label
+        and whether the set of fields and algorithm provide sufficient
+        entropy for load balancing.
+
+   T#19 Repeat pseudowire performance tests with Flow Labels included.
+
+4.5.  Entropy Label Support and Performance
+
+   T#20 Determine whether Entropy Labels can be added at ingress and
+        removed at egress.
+
+   T#21 Determine which fields are used to create an Entropy Label.
+        Labels further down in the stack, including Entropy Labels
+        further down and IP headers or IP payload fields where
+        applicable, should be used.  Determine whether the set of fields
+        and algorithm provide sufficient entropy for load balancing.
+
+   T#22 Repeat performance tests under "Basic Performance" when Entropy
+        Labels are used, where ingress or egress is the device under
+        test (DUT).
+
+   T#23 Determine whether an ELI is detected when acting as a midpoint
+        LSR and whether the search for further information on which to
+        base the load balancing is used.  Information below the Entropy
+        Label SHOULD NOT be used.
+
+   T#24 Ensure that the Entropy Label indicator and Entropy Label (ELI
+        and EL) are removed from the label stack during UHP and PHP
+        operations.
+
+
+
+
+Villamizar, et al.            Informational                    [Page 46]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+   T#25 Ensure that operations on the TC field when adding and removing
+        Entropy Label are correctly carried out.  If TC is changed
+        during a swap operation, the ability to transfer that change
+        MUST be provided.  The ability to suppress the transfer of TC
+        MUST also be provided.  See the pipe, short-pipe, and uniform
+        models in [RFC3443].
+
+   T#26 Repeat performance tests for a midpoint LSR with Entropy Labels
+        found at various label stack depths.
+
+4.6.  DoS Protection
+
+   T#27 Actively attack LSRs under high protocol churn load and
+        determine control-plane performance impact or successful DoS
+        under test conditions.  Specifically, test for the following.
+
+        A.  TCP SYN attack against control-plane and management-plane
+            protocols using TCP, including CLI access (typically SSH-
+            protected login), NETCONF, etc.
+
+        B.  High traffic volume attack against control-plane and
+            management-plane protocols not using TCP.
+
+        C.  Attacks that can be performed from a compromised management
+            subnet computer, but not one with authentication keys.
+
+        D.  Attacks that can be performed from a compromised peer within
+            the control plane (internal domain and external domain).
+            Assume that keys that are per peering and keys that are per
+            router ID, rather than network-wide keys, are in use.
+
+        See Section 2.6.1.
+
+4.7.  OAM Capabilities and Performance
+
+   T#28 Determine maximum sustainable rates of BFD traffic.  If BFD
+        requires CPU intervention, determine both maximum rates and CPU
+        loading when multiple interfaces are active.
+
+   T#29 Verify LSP Ping and LSP Traceroute capability.
+
+   T#30 Determine maximum rates of MPLS-TP CC-CV traffic.  If CC-CV
+        requires CPU intervention, determine both maximum rates and CPU
+        loading when multiple interfaces are active.
+
+   T#31 Determine MPLS-TP DM precision.
+
+   T#32 Determine MPLS-TP LM accuracy.
+
+
+
+Villamizar, et al.            Informational                    [Page 47]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+   T#33 Verify MPLS-TP AIS/RDI and Protection State Coordination (PSC)
+        functionality, protection speed, and AIS/RDI notification speed
+        when a large number of Maintenance Entities (MEs) must be
+        notified with AIS/RDI.
+
+5.  Security Considerations
+
+   This document reviews forwarding behavior specified elsewhere and
+   points out compliance and performance requirements.  As such, it
+   introduces no new security requirements or concerns.
+
+   Discussion of hardware support and other equipment hardening against
+   DoS attack can be found in Section 2.6.1.  Section 3.6 provides a
+   list of questions regarding DoS to be asked of suppliers.
+   Section 4.6 suggests types of testing that can provide some assurance
+   of the effectiveness of a supplier's claims about DoS hardening.
+
+   Knowledge of potential performance shortcomings may serve to help new
+   implementations avoid pitfalls.  It is unlikely that such knowledge
+   could be the basis of new denial of service, as these pitfalls are
+   already widely known in the service provider community and among
+   leading equipment suppliers.  In practice, extreme data and packet
+   rates are needed to affect existing equipment and to affect networks
+   that may be still vulnerable due to failure to implement adequate
+   protection.  The extreme data and packet rates make this type of
+   denial of service unlikely and make undetectable denial of service of
+   this type impossible.
+
+   Each normative reference contains security considerations.  A brief
+   summarization of MPLS security considerations applicable to
+   forwarding follows:
+
+   1.   MPLS encapsulation does not support an authentication extension.
+        This is reflected in the security section of [RFC3032].
+        Documents that clarify MPLS header fields such as TTL [RFC3443],
+        the explicit null label [RFC4182], renaming EXP to TC [RFC5462],
+        ECN for MPLS [RFC5129], and MPLS Ethernet encapsulation
+        [RFC5332] make no changes to security considerations in
+        [RFC3032].
+
+   2.   Some cited RFCs are related to Diffserv forwarding.  [RFC3270]
+        refers to MPLS and Diffserv security.  [RFC2474] mentions theft
+        of service and denial of service due to mismarking.  [RFC2474]
+        mentions IPsec interaction, but with MPLS, not being carried by
+        IP, the type of interaction in [RFC2474] is not relevant.
+
+
+
+
+
+
+Villamizar, et al.            Informational                    [Page 48]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+   3.   [RFC3209] is cited here due only to make-before-break forwarding
+        requirements.  This is related to resource sharing and the
+        theft-of-service and denial-of-service concerns in [RFC2474]
+        apply.
+
+   4.   [RFC4090] defines FRR, which provides protection but does not
+        add security concerns.  RFC 4201 defines link bundling but
+        raises no additional security concerns.
+
+   5.   Various OAM control channels are defined in [RFC4385] (PW CW),
+        [RFC5085] (VCCV), and [RFC5586] (G-Ach and GAL).  These
+        documents describe potential abuse of these OAM control
+        channels.
+
+   6.   [RFC4950] defines ICMP extensions when MPLS TTL expires and the
+        payload is IP.  This provides MPLS header information that is of
+        no use to an IP attacker, but sending this information can be
+        suppressed through configuration.
+
+   7.   GTSM [RFC5082] provides a means to improve protection against
+        high traffic volume spoofing as a form of DoS attack.
+
+   8.   BFD [RFC5880] [RFC5884] [RFC5885] provides a form of OAM used in
+        MPLS and MPLS-TP.  The security considerations related to the
+        OAM control channel are relevant.  The BFD payload supports
+        authentication.  The MPLS encapsulation, the MPLS control
+        channel, or the PW control channel, which BFD may be carried in,
+        do not support authentication.  Where an IP return OAM path is
+        used, IPsec is suggested as a means of securing the return path.
+
+   9.   Other forms of OAM are supported by [RFC6374] [RFC6375] (Loss
+        and Delay Measurement), [RFC6428] (Continuity Check/Verification
+        based on BFD), and [RFC6427] (Fault Management).  The security
+        considerations related to the OAM control channel are relevant.
+        IP return paths, where used, can be secured with IPsec.
+
+   10.  Linear protection is defined by [RFC6378] and updated by
+        [RFC7324].  Security concerns related to MPLS encapsulation and
+        OAM control channels apply.  Security concerns reiterate
+        [RFC5920] as applied to protection switching.
+
+   11.  The PW Flow Label [RFC6391] and MPLS Entropy Label [RFC6790]
+        affect multipath load balancing.  Security concerns reiterate
+        [RFC5920].  Security impacts would be limited to load
+        distribution.
+
+
+
+
+
+
+Villamizar, et al.            Informational                    [Page 49]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+   MPLS security including data-plane security is discussed in greater
+   detail in [RFC5920] (MPLS/GMPLS Security Framework).  The MPLS-TP
+   security framework [RFC6941] builds upon this, focusing largely on
+   the MPLS-TP OAM additions and OAM channels with some attention given
+   to using network management in place of control-plane setup.  In both
+   security framework documents, MPLS is assumed to run within a
+   "trusted zone", defined as being where a single service provider has
+   total operational control over that part of the network.
+
+   If control-plane security and management-plane security are
+   sufficiently robust, compromise of a single network element may
+   result in chaos in the data plane anywhere in the network through
+   denial-of-service attacks, but not a Byzantine security failure in
+   which other network elements are fully compromised.
+
+   MPLS security, or lack thereof, can affect whether traffic can be
+   misrouted and lost, or intercepted, or intercepted and reinserted (a
+   man-in-the-middle attack), or spoofed.  End-user applications,
+   including control-plane and management-plane protocols used by the
+   service provider, are expected to make use of appropriate end-to-end
+   authentication and, where appropriate, end-to-end encryption.
+
+6.  Organization of References Section
+
+   The References section is split into Normative and Informative
+   subsections.  References that directly specify forwarding
+   encapsulations or behaviors are listed as normative.  References that
+   describe signaling only, though normative with respect to signaling,
+   are listed as informative.  They are informative with respect to MPLS
+   forwarding.
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3032]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
+              Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
+              Encoding", RFC 3032, January 2001.
+
+   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
+              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
+              Tunnels", RFC 3209, December 2001.
+
+
+
+
+
+
+Villamizar, et al.            Informational                    [Page 50]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+   [RFC3270]  Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
+              P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
+              Protocol Label Switching (MPLS) Support of Differentiated
+              Services", RFC 3270, May 2002.
+
+   [RFC3443]  Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing
+              in Multi-Protocol Label Switching (MPLS) Networks", RFC
+              3443, January 2003.
+
+   [RFC4090]  Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
+              Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May
+              2005.
+
+   [RFC4182]  Rosen, E., "Removing a Restriction on the use of MPLS
+              Explicit NULL", RFC 4182, September 2005.
+
+   [RFC4201]  Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
+              in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
+
+   [RFC4385]  Bryant, S., Swallow, G., Martini, L., and D. McPherson,
+              "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
+              Use over an MPLS PSN", RFC 4385, February 2006.
+
+   [RFC4950]  Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP
+              Extensions for Multiprotocol Label Switching", RFC 4950,
+              August 2007.
+
+   [RFC5082]  Gill, V., Heasley, J., Meyer, D., Savola, P., and C.
+              Pignataro, "The Generalized TTL Security Mechanism
+              (GTSM)", RFC 5082, October 2007.
+
+   [RFC5085]  Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
+              Connectivity Verification (VCCV): A Control Channel for
+              Pseudowires", RFC 5085, December 2007.
+
+   [RFC5129]  Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion
+              Marking in MPLS", RFC 5129, January 2008.
+
+   [RFC5332]  Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS
+              Multicast Encapsulations", RFC 5332, August 2008.
+
+   [RFC5586]  Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
+              Associated Channel", RFC 5586, June 2009.
+
+   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
+              (BFD)", RFC 5880, June 2010.
+
+
+
+
+
+Villamizar, et al.            Informational                    [Page 51]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+   [RFC5884]  Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
+              "Bidirectional Forwarding Detection (BFD) for MPLS Label
+              Switched Paths (LSPs)", RFC 5884, June 2010.
+
+   [RFC5885]  Nadeau, T. and C. Pignataro, "Bidirectional Forwarding
+              Detection (BFD) for the Pseudowire Virtual Circuit
+              Connectivity Verification (VCCV)", RFC 5885, June 2010.
+
+   [RFC6374]  Frost, D. and S. Bryant, "Packet Loss and Delay
+              Measurement for MPLS Networks", RFC 6374, September 2011.
+
+   [RFC6375]  Frost, D. and S. Bryant, "A Packet Loss and Delay
+              Measurement Profile for MPLS-Based Transport Networks",
+              RFC 6375, September 2011.
+
+   [RFC6378]  Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and
+              A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear
+              Protection", RFC 6378, October 2011.
+
+   [RFC6391]  Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan,
+              J., and S. Amante, "Flow-Aware Transport of Pseudowires
+              over an MPLS Packet Switched Network", RFC 6391, November
+              2011.
+
+   [RFC6427]  Swallow, G., Fulignoli, A., Vigoureux, M., Boutros, S.,
+              and D. Ward, "MPLS Fault Management Operations,
+              Administration, and Maintenance (OAM)", RFC 6427, November
+              2011.
+
+   [RFC6428]  Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive
+              Connectivity Verification, Continuity Check, and Remote
+              Defect Indication for the MPLS Transport Profile", RFC
+              6428, November 2011.
+
+   [RFC6790]  Kompella, K., Drake, J., Amante, S., Henderickx, W., and
+              L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
+              RFC 6790, November 2012.
+
+   [RFC7324]  Osborne, E., "Updates to MPLS Transport Profile Linear
+              Protection", RFC 7324, July 2014.
+
+
+
+
+
+
+
+
+
+
+
+Villamizar, et al.            Informational                    [Page 52]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+7.2.  Informative References
+
+   [ACK-compression]
+              Zhang, L., Shenker, S., and D. Clark, "Observations and
+              Dynamics of a Congestion Control Algorithm: The Effects of
+              Two-Way Traffic", Proc. ACM SIGCOMM, ACM Computer
+              Communications Review (CCR) Vol. 21, No. 4, pp. 133-147.,
+              1991.
+
+   [MPLS-IN-UDP]
+              Xu, X., Sheth, N., Yong, L., Pignataro, C., and F.
+              Yongbing, "Encapsulating MPLS in UDP", Work in Progress,
+              January 2014.
+
+   [MRT]      Atlas, A., Kebler, R., Bowers, C., Envedi, G., Csaszar,
+              A., Tantsura, J., Konstantynowicz, M., and R. White, "An
+              Architecture for IP/LDP Fast-Reroute Using Maximally
+              Redundant Trees", Work in Progress, July 2014.
+
+   [REMOTE-LFA]
+              Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S.
+              Ning, "Remote LFA FRR", Work in Progress, May 2014.
+
+   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
+              1981.
+
+   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
+              "Definition of the Differentiated Services Field (DS
+              Field) in the IPv4 and IPv6 Headers", RFC 2474, December
+              1998.
+
+   [RFC2475]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
+              and W. Weiss, "An Architecture for Differentiated
+              Services", RFC 2475, December 1998.
+
+   [RFC2597]  Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
+              "Assured Forwarding PHB Group", RFC 2597, June 1999.
+
+   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
+              Label Switching Architecture", RFC 3031, January 2001.
+
+   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
+              of Explicit Congestion Notification (ECN) to IP", RFC
+              3168, September 2001.
+
+
+
+
+
+
+
+Villamizar, et al.            Informational                    [Page 53]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+   [RFC3429]  Ohta, H., "Assignment of the 'OAM Alert Label' for
+              Multiprotocol Label Switching Architecture (MPLS)
+              Operation and Maintenance (OAM) Functions", RFC 3429,
+              November 2002.
+
+   [RFC3471]  Berger, L., "Generalized Multi-Protocol Label Switching
+              (GMPLS) Signaling Functional Description", RFC 3471,
+              January 2003.
+
+   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
+              Jacobson, "RTP: A Transport Protocol for Real-Time
+              Applications", STD 64, RFC 3550, July 2003.
+
+   [RFC3828]  Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
+              G. Fairhurst, "The Lightweight User Datagram Protocol
+              (UDP-Lite)", RFC 3828, July 2004.
+
+   [RFC3985]  Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
+              Edge (PWE3) Architecture", RFC 3985, March 2005.
+
+   [RFC4023]  Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating
+              MPLS in IP or Generic Routing Encapsulation (GRE)", RFC
+              4023, March 2005.
+
+   [RFC4110]  Callon, R. and M. Suzuki, "A Framework for Layer 3
+              Provider-Provisioned Virtual Private Networks (PPVPNs)",
+              RFC 4110, July 2005.
+
+   [RFC4124]  Le Faucheur, F., "Protocol Extensions for Support of
+              Diffserv-aware MPLS Traffic Engineering", RFC 4124, June
+              2005.
+
+   [RFC4206]  Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
+              Hierarchy with Generalized Multi-Protocol Label Switching
+              (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
+
+   [RFC4221]  Nadeau, T., Srinivasan, C., and A. Farrel, "Multiprotocol
+              Label Switching (MPLS) Management Overview", RFC 4221,
+              November 2005.
+
+   [RFC4340]  Kohler, E., Handley, M., and S. Floyd, "Datagram
+              Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
+
+   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
+              Networks (VPNs)", RFC 4364, February 2006.
+
+
+
+
+
+
+Villamizar, et al.            Informational                    [Page 54]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+   [RFC4377]  Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S.
+              Matsushima, "Operations and Management (OAM) Requirements
+              for Multi-Protocol Label Switched (MPLS) Networks", RFC
+              4377, February 2006.
+
+   [RFC4379]  Kompella, K. and G. Swallow, "Detecting Multi-Protocol
+              Label Switched (MPLS) Data Plane Failures", RFC 4379,
+              February 2006.
+
+   [RFC4664]  Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual
+              Private Networks (L2VPNs)", RFC 4664, September 2006.
+
+   [RFC4817]  Townsley, M., Pignataro, C., Wainner, S., Seely, T., and
+              J. Young, "Encapsulation of MPLS over Layer 2 Tunneling
+              Protocol Version 3", RFC 4817, March 2007.
+
+   [RFC4875]  Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
+              "Extensions to Resource Reservation Protocol - Traffic
+              Engineering (RSVP-TE) for Point-to-Multipoint TE Label
+              Switched Paths (LSPs)", RFC 4875, May 2007.
+
+   [RFC4928]  Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal
+              Cost Multipath Treatment in MPLS Networks", BCP 128, RFC
+              4928, June 2007.
+
+   [RFC4960]  Stewart, R., "Stream Control Transmission Protocol", RFC
+              4960, September 2007.
+
+   [RFC5036]  Andersson, L., Minei, I., and B. Thomas, "LDP
+              Specification", RFC 5036, October 2007.
+
+   [RFC5286]  Atlas, A. and A. Zinin, "Basic Specification for IP Fast
+              Reroute: Loop-Free Alternates", RFC 5286, September 2008.
+
+   [RFC5317]  Bryant, S. and L. Andersson, "Joint Working Team (JWT)
+              Report on MPLS Architectural Considerations for a
+              Transport Profile", RFC 5317, February 2009.
+
+   [RFC5462]  Andersson, L. and R. Asati, "Multiprotocol Label Switching
+              (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
+              Class" Field", RFC 5462, February 2009.
+
+   [RFC5470]  Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek,
+              "Architecture for IP Flow Information Export", RFC 5470,
+              March 2009.
+
+   [RFC5640]  Filsfils, C., Mohapatra, P., and C. Pignataro, "Load-
+              Balancing for Mesh Softwires", RFC 5640, August 2009.
+
+
+
+Villamizar, et al.            Informational                    [Page 55]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+   [RFC5695]  Akhter, A., Asati, R., and C. Pignataro, "MPLS Forwarding
+              Benchmarking Methodology for IP Flows", RFC 5695, November
+              2009.
+
+   [RFC5704]  Bryant, S., Morrow, M., and IAB, "Uncoordinated Protocol
+              Development Considered Harmful", RFC 5704, November 2009.
+
+   [RFC5714]  Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC
+              5714, January 2010.
+
+   [RFC5715]  Shand, M. and S. Bryant, "A Framework for Loop-Free
+              Convergence", RFC 5715, January 2010.
+
+   [RFC5860]  Vigoureux, M., Ward, D., and M. Betts, "Requirements for
+              Operations, Administration, and Maintenance (OAM) in MPLS
+              Transport Networks", RFC 5860, May 2010.
+
+   [RFC5905]  Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
+              Time Protocol Version 4: Protocol and Algorithms
+              Specification", RFC 5905, June 2010.
+
+   [RFC5920]  Fang, L., "Security Framework for MPLS and GMPLS
+              Networks", RFC 5920, July 2010.
+
+   [RFC6291]  Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
+              D., and S. Mansfield, "Guidelines for the Use of the "OAM"
+              Acronym in the IETF", BCP 161, RFC 6291, June 2011.
+
+   [RFC6310]  Aissaoui, M., Busschbach, P., Martini, L., Morrow, M.,
+              Nadeau, T., and Y(J). Stein, "Pseudowire (PW) Operations,
+              Administration, and Maintenance (OAM) Message Mapping",
+              RFC 6310, July 2011.
+
+   [RFC6371]  Busi, I. and D. Allan, "Operations, Administration, and
+              Maintenance Framework for MPLS-Based Transport Networks",
+              RFC 6371, September 2011.
+
+   [RFC6388]  Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas,
+              "Label Distribution Protocol Extensions for Point-to-
+              Multipoint and Multipoint-to-Multipoint Label Switched
+              Paths", RFC 6388, November 2011.
+
+   [RFC6424]  Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for
+              Performing Label Switched Path Ping (LSP Ping) over MPLS
+              Tunnels", RFC 6424, November 2011.
+
+
+
+
+
+
+Villamizar, et al.            Informational                    [Page 56]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+   [RFC6425]  Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa,
+              S., and T. Nadeau, "Detecting Data-Plane Failures in
+              Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC
+              6425, November 2011.
+
+   [RFC6426]  Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS
+              On-Demand Connectivity Verification and Route Tracing",
+              RFC 6426, November 2011.
+
+   [RFC6435]  Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, M.,
+              and X. Dai, "MPLS Transport Profile Lock Instruct and
+              Loopback Functions", RFC 6435, November 2011.
+
+   [RFC6438]  Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
+              for Equal Cost Multipath Routing and Link Aggregation in
+              Tunnels", RFC 6438, November 2011.
+
+   [RFC6478]  Martini, L., Swallow, G., Heron, G., and M. Bocci,
+              "Pseudowire Status for Static Pseudowires", RFC 6478, May
+              2012.
+
+   [RFC6639]  King, D. and M. Venkatesan, "Multiprotocol Label Switching
+              Transport Profile (MPLS-TP) MIB-Based Management
+              Overview", RFC 6639, June 2012.
+
+   [RFC6669]  Sprecher, N. and L. Fang, "An Overview of the Operations,
+              Administration, and Maintenance (OAM) Toolset for MPLS-
+              Based Transport Networks", RFC 6669, July 2012.
+
+   [RFC6670]  Sprecher, N. and KY. Hong, "The Reasons for Selecting a
+              Single Solution for MPLS Transport Profile (MPLS-TP)
+              Operations, Administration, and Maintenance (OAM)", RFC
+              6670, July 2012.
+
+   [RFC6720]  Pignataro, C. and R. Asati, "The Generalized TTL Security
+              Mechanism (GTSM) for the Label Distribution Protocol
+              (LDP)", RFC 6720, August 2012.
+
+   [RFC6829]  Chen, M., Pan, P., Pignataro, C., and R. Asati, "Label
+              Switched Path (LSP) Ping for Pseudowire Forwarding
+              Equivalence Classes (FECs) Advertised over IPv6", RFC
+              6829, January 2013.
+
+   [RFC6894]  Papneja, R., Vapiwala, S., Karthik, J., Poretsky, S., Rao,
+              S., and JL. Le Roux, "Methodology for Benchmarking MPLS
+              Traffic Engineered (MPLS-TE) Fast Reroute Protection", RFC
+              6894, March 2013.
+
+
+
+
+Villamizar, et al.            Informational                    [Page 57]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+   [RFC6941]  Fang, L., Niven-Jenkins, B., Mansfield, S., and R.
+              Graveman, "MPLS Transport Profile (MPLS-TP) Security
+              Framework", RFC 6941, April 2013.
+
+   [RFC6981]  Bryant, S., Previdi, S., and M. Shand, "A Framework for IP
+              and MPLS Fast Reroute Using Not-Via Addresses", RFC 6981,
+              August 2013.
+
+   [RFC7012]  Claise, B. and B. Trammell, "Information Model for IP Flow
+              Information Export (IPFIX)", RFC 7012, September 2013.
+
+   [RFC7023]  Mohan, D., Bitar, N., Sajassi, A., DeLord, S., Niger, P.,
+              and R. Qiu, "MPLS and Ethernet Operations, Administration,
+              and Maintenance (OAM) Interworking", RFC 7023, October
+              2013.
+
+   [RFC7074]  Berger, L. and J. Meuric, "Revised Definition of the GMPLS
+              Switching Capability and Type Fields", RFC 7074, November
+              2013.
+
+   [RFC7079]  Del Regno, N. and A. Malis, "The Pseudowire (PW) and
+              Virtual Circuit Connectivity Verification (VCCV)
+              Implementation Survey Results", RFC 7079, November 2013.
+
+   [RFC7274]  Kompella, K., Andersson, L., and A. Farrel, "Allocating
+              and Retiring Special-Purpose MPLS Labels", RFC 7274, June
+              2014.
+
+   [TIMING-OVER-MPLS]
+              Davari, S., Oren, A., Bhatia, M., Roberts, P., and L.
+              Montini, "Transporting Timing messages over MPLS
+              Networks", Work in Progress, April 2014.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Villamizar, et al.            Informational                    [Page 58]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+Appendix A.  Acknowledgements
+
+   Numerous very useful comments have been received in private email.
+   Some of these contributions are acknowledged here, approximately in
+   chronologic order.
+
+   Paul Doolan provided a brief review resulting in a number of
+   clarifications, most notably regarding on-chip vs. system buffering,
+   100 Gb/s link speed assumptions in the 150 Mpps figure, and handling
+   of large microflows.  Pablo Frank reminded us of the sawtooth effect
+   in PPS vs. packet-size graphs, prompting the addition of a few
+   paragraphs on this.  Comments from Lou Berger at IETF 85 prompted the
+   addition of Section 2.7.
+
+   Valuable comments were received on the BMWG mailing list.  Jay
+   Karthik pointed out testing methodology hints that after discussion
+   were deemed out of scope and were removed but may benefit later work
+   in BMWG.
+
+   Nabil Bitar pointed out the need to cover QoS (Differentiated
+   Services), MPLS multicast (P2MP and MP2MP), and MPLS-TP OAM.  Nabil
+   also provided a number of clarifications to the questions and tests
+   in Sections 3 and 4.
+
+   Mark Szczesniak provided a thorough review and a number of useful
+   comments and suggestions that improved the document.
+
+   Gregory Mirsky and Thomas Beckhaus provided useful comments during
+   the review by the MPLS Review Team.
+
+   Tal Mizrahi provided comments that prompted clarifications regarding
+   timestamp processing, local delivery of packets, and the need for
+   hardware assistance in processing OAM traffic.
+
+   Alexander (Sasha) Vainshtein pointed out errors in Section 2.1.8.1
+   and suggested new text that, after lengthy discussion, resulted in
+   restating the summarization of requirements from PWE3 RFCs and more
+   clearly stating the benefits and drawbacks of packet resequencing
+   based on PW Sequence Number.
+
+   Loa Anderson provided useful comments and corrections prior to WGLC.
+   Adrian Farrel provided useful comments and corrections prior as part
+   of the AD review.
+
+   Discussion with Steve Kent during SecDir review resulted in expansion
+   of Section 5, briefly summarizing security considerations related to
+   forwarding in normative references.  Tom Petch pointed out some
+   editorial errors in private email plus an important math error.  Al
+
+
+
+Villamizar, et al.            Informational                    [Page 59]
+
+RFC 7325                     MPLS Forwarding                 August 2014
+
+
+   Morton during OpsDir review prompted clarification in the section
+   about the target audience, suggested more clear wording in places,
+   and found numerous editorial errors.
+
+   Discussion with Stewart Bryant and Alia Atlas as part of IESG review
+   resulted in coverage of IPFIX and improvements to document coverage
+   of MPLS FRR, and IP/LDP FRR, plus some corrections to the text
+   elsewhere.
+
+Authors' Addresses
+
+   Curtis Villamizar (editor)
+   Outer Cape Cod Network Consulting, LLC
+
+   EMail: curtis@occnc.com
+
+
+   Kireeti Kompella
+   Juniper Networks
+
+   EMail: kireeti@juniper.net
+
+
+   Shane Amante
+   Apple Inc.
+   1 Infinite Loop
+   Cupertino, California  95014
+
+   EMail: amante@apple.com
+
+
+   Andrew Malis
+   Huawei Technologies
+
+   EMail: agmalis@gmail.com
+
+
+   Carlos Pignataro
+   Cisco Systems
+   7200-12 Kit Creek Road
+   Research Triangle Park, NC  27709
+   US
+
+   EMail: cpignata@cisco.com
+
+
+
+
+
+
+
+Villamizar, et al.            Informational                    [Page 60]
+