GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7325

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7325.txt · Last modified: 2014/08/07 19:21 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki