< draft-ietf-mpls-forwarding-04.txt   draft-ietf-mpls-forwarding-05.txt >
MPLS C. Villamizar, Ed. MPLS C. Villamizar, Ed.
Internet-Draft OCCNC Internet-Draft OCCNC
Intended status: Informational K. Kompella Intended status: Informational K. Kompella
Expires: June 20, 2014 Juniper Networks Expires: August 01, 2014 Juniper Networks
S. Amante S. Amante
Apple Inc. Apple Inc.
A. Malis A. Malis
Consultant Huawei
C. Pignataro C. Pignataro
Cisco Cisco
December 17, 2013 January 28, 2014
MPLS Forwarding Compliance and Performance Requirements MPLS Forwarding Compliance and Performance Requirements
draft-ietf-mpls-forwarding-04 draft-ietf-mpls-forwarding-05
Abstract Abstract
This document provides guidelines for implementers regarding MPLS This document provides guidelines for implementers regarding MPLS
forwarding and a basis for evaluations of forwarding implementations. forwarding and a basis for evaluations of forwarding implementations.
Guidelines cover many aspects of MPLS forwarding. Topics are Guidelines cover many aspects of MPLS forwarding. Topics are
highlighted where implementers might otherwise overlook practical highlighted where implementers might otherwise overlook practical
requirements which are unstated or under emphasized or are optional requirements which are unstated or under emphasized or are optional
for conformance to RFCs but are often considered mandatory by for conformance to RFCs but are often considered mandatory by
providers. providers.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 20, 2014. This Internet-Draft will expire on August 01, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction and Document Scope . . . . . . . . . . . . . . . 3 1. Introduction and Document Scope . . . . . . . . . . . . . . . 3
1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Use of Requirements Language . . . . . . . . . . . . . . 8 1.2. Use of Requirements Language . . . . . . . . . . . . . . 8
1.3. Apparent Misconceptions . . . . . . . . . . . . . . . . . 8 1.3. Apparent Misconceptions . . . . . . . . . . . . . . . . . 8
1.4. Target Audience . . . . . . . . . . . . . . . . . . . . . 9 1.4. Target Audience . . . . . . . . . . . . . . . . . . . . . 10
2. Forwarding Issues . . . . . . . . . . . . . . . . . . . . . . 10 2. Forwarding Issues . . . . . . . . . . . . . . . . . . . . . . 10
2.1. Forwarding Basics . . . . . . . . . . . . . . . . . . . . 10 2.1. Forwarding Basics . . . . . . . . . . . . . . . . . . . . 10
2.1.1. MPLS Special Purpose Labels . . . . . . . . . . . . . 11 2.1.1. MPLS Special Purpose Labels . . . . . . . . . . . . . 11
2.1.2. MPLS Differentiated Services . . . . . . . . . . . . 12 2.1.2. MPLS Differentiated Services . . . . . . . . . . . . 12
2.1.3. Time Synchronization . . . . . . . . . . . . . . . . 13 2.1.3. Time Synchronization . . . . . . . . . . . . . . . . 13
2.1.4. Uses of Multiple Label Stack Entries . . . . . . . . 14 2.1.4. Uses of Multiple Label Stack Entries . . . . . . . . 14
2.1.5. MPLS Link Bundling . . . . . . . . . . . . . . . . . 15 2.1.5. MPLS Link Bundling . . . . . . . . . . . . . . . . . 15
2.1.6. MPLS Hierarchy . . . . . . . . . . . . . . . . . . . 15 2.1.6. MPLS Hierarchy . . . . . . . . . . . . . . . . . . . 15
2.1.7. MPLS Fast Reroute (FRR) . . . . . . . . . . . . . . . 15 2.1.7. MPLS Fast Reroute (FRR) . . . . . . . . . . . . . . . 15
2.1.8. Pseudowire Encapsulation . . . . . . . . . . . . . . 16 2.1.8. Pseudowire Encapsulation . . . . . . . . . . . . . . 16
2.1.8.1. Pseudowire Sequence Number . . . . . . . . . . . 16 2.1.8.1. Pseudowire Sequence Number . . . . . . . . . . . 16
2.1.9. Layer-2 and Layer-3 VPN . . . . . . . . . . . . . . . 18 2.1.9. Layer-2 and Layer-3 VPN . . . . . . . . . . . . . . . 18
2.2. MPLS Multicast . . . . . . . . . . . . . . . . . . . . . 18 2.2. MPLS Multicast . . . . . . . . . . . . . . . . . . . . . 18
2.3. Packet Rates . . . . . . . . . . . . . . . . . . . . . . 19 2.3. Packet Rates . . . . . . . . . . . . . . . . . . . . . . 19
2.4. MPLS Multipath Techniques . . . . . . . . . . . . . . . . 21 2.4. MPLS Multipath Techniques . . . . . . . . . . . . . . . . 21
2.4.1. Pseudowire Control Word . . . . . . . . . . . . . . . 22 2.4.1. Pseudowire Control Word . . . . . . . . . . . . . . . 22
2.4.2. Large Microflows . . . . . . . . . . . . . . . . . . 22 2.4.2. Large Microflows . . . . . . . . . . . . . . . . . . 23
2.4.3. Pseudowire Flow Label . . . . . . . . . . . . . . . . 23 2.4.3. Pseudowire Flow Label . . . . . . . . . . . . . . . . 23
2.4.4. MPLS Entropy Label . . . . . . . . . . . . . . . . . 23 2.4.4. MPLS Entropy Label . . . . . . . . . . . . . . . . . 23
2.4.5. Fields Used for Multipath Load Balance . . . . . . . 23 2.4.5. Fields Used for Multipath Load Balance . . . . . . . 24
2.4.5.1. MPLS Fields in Multipath . . . . . . . . . . . . 24 2.4.5.1. MPLS Fields in Multipath . . . . . . . . . . . . 24
2.4.5.2. IP Fields in Multipath . . . . . . . . . . . . . 25 2.4.5.2. IP Fields in Multipath . . . . . . . . . . . . . 26
2.4.5.3. Fields Used in Flow Label . . . . . . . . . . . . 27 2.4.5.3. Fields Used in Flow Label . . . . . . . . . . . . 28
2.4.5.4. Fields Used in Entropy Label . . . . . . . . . . 27 2.4.5.4. Fields Used in Entropy Label . . . . . . . . . . 28
2.5. MPLS-TP and UHP . . . . . . . . . . . . . . . . . . . . . 28 2.5. MPLS-TP and UHP . . . . . . . . . . . . . . . . . . . . . 28
2.6. Local Delivery of Packets . . . . . . . . . . . . . . . . 28 2.6. Local Delivery of Packets . . . . . . . . . . . . . . . . 29
2.6.1. DoS Protection . . . . . . . . . . . . . . . . . . . 28 2.6.1. DoS Protection . . . . . . . . . . . . . . . . . . . 29
2.6.2. MPLS OAM . . . . . . . . . . . . . . . . . . . . . . 30 2.6.2. MPLS OAM . . . . . . . . . . . . . . . . . . . . . . 31
2.6.3. Pseudowire OAM . . . . . . . . . . . . . . . . . . . 31 2.6.3. Pseudowire OAM . . . . . . . . . . . . . . . . . . . 32
2.6.4. MPLS-TP OAM . . . . . . . . . . . . . . . . . . . . . 32 2.6.4. MPLS-TP OAM . . . . . . . . . . . . . . . . . . . . . 32
2.6.5. MPLS OAM and Layer-2 OAM Interworking . . . . . . . . 33 2.6.5. MPLS OAM and Layer-2 OAM Interworking . . . . . . . . 34
2.6.6. Extent of OAM Support by Hardware . . . . . . . . . . 33 2.6.6. Extent of OAM Support by Hardware . . . . . . . . . . 34
2.7. Number and Size of Flows . . . . . . . . . . . . . . . . 34 2.7. Number and Size of Flows . . . . . . . . . . . . . . . . 35
3. Questions for Suppliers . . . . . . . . . . . . . . . . . . . 35 3. Questions for Suppliers . . . . . . . . . . . . . . . . . . . 36
3.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . 35 3.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . 36
3.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 36 3.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 38
3.3. Multipath Capabilities and Performance . . . . . . . . . 37 3.3. Multipath Capabilities and Performance . . . . . . . . . 38
3.4. Pseudowire Capabilities and Performance . . . . . . . . . 38 3.4. Pseudowire Capabilities and Performance . . . . . . . . . 39
3.5. Entropy Label Support and Performance . . . . . . . . . . 38 3.5. Entropy Label Support and Performance . . . . . . . . . . 39
3.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . 38 3.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . 40
3.7. OAM Capabilities and Performance . . . . . . . . . . . . 39 3.7. OAM Capabilities and Performance . . . . . . . . . . . . 40
4. Forwarding Compliance and Performance Testing . . . . . . . . 39 4. Forwarding Compliance and Performance Testing . . . . . . . . 40
4.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . 40 4.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . 41
4.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 40 4.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 41
4.3. Multipath Capabilities and Performance . . . . . . . . . 41 4.3. Multipath Capabilities and Performance . . . . . . . . . 42
4.4. Pseudowire Capabilities and Performance . . . . . . . . . 42 4.4. Pseudowire Capabilities and Performance . . . . . . . . . 43
4.5. Entropy Label Support and Performance . . . . . . . . . . 42 4.5. Entropy Label Support and Performance . . . . . . . . . . 43
4.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . 43 4.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . 44
4.7. OAM Capabilities and Performance . . . . . . . . . . . . 43 4.7. OAM Capabilities and Performance . . . . . . . . . . . . 45
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
7. Security Considerations . . . . . . . . . . . . . . . . . . . 45 7. Security Considerations . . . . . . . . . . . . . . . . . . . 46
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 46
8.1. Normative References . . . . . . . . . . . . . . . . . . 45 8.1. Normative References . . . . . . . . . . . . . . . . . . 46
8.2. Informative References . . . . . . . . . . . . . . . . . 46 8.2. Informative References . . . . . . . . . . . . . . . . . 49
Appendix A. Organization of References Section . . . . . . . . . 51 Appendix A. Organization of References Section . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
1. Introduction and Document Scope 1. Introduction and Document Scope
The initial purpose of this document was to address concerns raised The initial purpose of this document was to address concerns raised
on the MPLS WG mailing list about shortcomings in implementations of on the MPLS WG mailing list about shortcomings in implementations of
MPLS forwarding. Documenting existing misconceptions and potential MPLS forwarding. Documenting existing misconceptions and potential
pitfalls might potentially avoid repeating past mistakes. The pitfalls might potentially avoid repeating past mistakes. The
document has grown to address a broad set of forwarding requirements. document has grown to address a broad set of forwarding requirements.
The focus of this document is MPLS forwarding, base pseudowire The focus of this document is MPLS forwarding, base pseudowire
forwarding, and MPLS OAM. The use of pseudowire control word, and forwarding, and MPLS Operations, Administration, and Maintenance
sequence number are discussed. Specific pseudowire AC and NSP are (OAM). The use of pseudowire control word, and sequence number are
out of scope. Specific pseudowire applications, such as various discussed. Specific pseudowire Attachment Circuit (AC) and Native
forms of VPN, are out of scope. 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 MPLS support for multipath techniques is considered essential by many
service providers and is useful for other high capacity networks. In service providers and is useful for other high capacity networks. In
order to obtain sufficient entropy from MPLS traffic service order to obtain sufficient entropy from MPLS traffic service
providers and others find it essential for the MPLS implementation to providers and others find it essential for the MPLS implementation to
interpret the MPLS payload as IPv4 or IPv6 based on the contents of 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 the first nibble of payload. The use of IP addresses, the IP
protocol field, and UDP and TCP port number fields in multipath load protocol field, and UDP and TCP port number fields in multipath load
balancing are considered within scope. The use of any other IP balancing are considered within scope. The use of any other IP
protocol fields, such as tunneling protocols carried within IP, are protocol fields, such as tunneling protocols carried within IP, are
skipping to change at page 4, line 44 skipping to change at page 4, line 47
AIS Alarm Indication Signal (MPLS-TP OAM) AIS Alarm Indication Signal (MPLS-TP OAM)
ATM Asynchronous Transfer Mode (legacy switched circuits) ATM Asynchronous Transfer Mode (legacy switched circuits)
BFD Bidirectional Forwarding Detection BFD Bidirectional Forwarding Detection
BGP Border Gateway Protocol BGP Border Gateway Protocol
CC-CV Connectivity Check and Connectivity Verification CC-CV Connectivity Check and Connectivity Verification
CE Customer Edge (LDP) CE Customer Edge (LDP, RSVP-TE, other protocols)
CPU Central Processing Unit (computer or microprocessor) CPU Central Processing Unit (computer or microprocessor)
CT Class Type ([RFC4124]) CT Class Type ([RFC4124])
CW Control Word ([RFC4385]) CW Control Word ([RFC4385])
DCCP Datagram Congestion Control Protocol DCCP Datagram Congestion Control Protocol
DDoS Distributed Denial of Service DDoS Distributed Denial of Service
DM Delay Measurement (MPLS-TP OAM) DM Delay Measurement (MPLS-TP OAM)
DSCP Differentiated Services Code Point ([RFC2474]) DSCP Differentiated Services Code Point ([RFC2474])
DWDM Dense Wave Division Multiplexing DWDM Dense Wave Division Multiplexing
skipping to change at page 6, line 44 skipping to change at page 6, line 46
NSP Native Service Processing ([RFC3985]) NSP Native Service Processing ([RFC3985])
NTP Network Time Protocol NTP Network Time Protocol
OAM Operations, Administration, and Maintenance ([RFC6291]) OAM Operations, Administration, and Maintenance ([RFC6291])
OOB Out-of-band (not carried within a data channel) OOB Out-of-band (not carried within a data channel)
OTN Optical Transport Network OTN Optical Transport Network
P Provider router (LDP) P Provider router (LDP, RSVP-TE, other protocols)
P2MP Point to Multi-Point P2MP Point to Multi-Point
PE Provider Edge router (LDP) PE Provider Edge router (LDP, RSVP-TE, other protocols)
PHB Per-Hop-Behavior ([RFC2475]) PHB Per-Hop-Behavior ([RFC2475])
PHP Penultimate Hop Popping ([RFC3443]) PHP Penultimate Hop Popping ([RFC3443])
POS Packet over SONET POS Packet over SONET
PSC This acronym has multiple interpretations. PSC This acronym has multiple interpretations.
1. Packet Switch Capable ([RFC3471] 1. Packet Switch Capable ([RFC3471]
2. PHB Scheduling Class ([RFC3270]) 2. PHB Scheduling Class ([RFC3270])
3. Protection State Coordination (MPLS-TP linear protection) 3. Protection State Coordination ([RFC6378])
PTP Precision Time Protocol PTP Precision Time Protocol
PW Pseudowire PW Pseudowire
QoS Quality of Service QoS Quality of Service
RA Router Alert ([RFC3032]) RA Router Alert ([RFC3032])
RDI Remote Defect Indication (MPLS-TP OAM) RDI Remote Defect Indication (MPLS-TP OAM)
skipping to change at page 9, line 30 skipping to change at page 9, line 39
b. If indefinite full packet rate for small packets is not b. If indefinite full packet rate for small packets is not
practical, a forwarding engine MUST be able to buffer a long practical, a forwarding engine MUST be able to buffer a long
sequence of small packets inbound to the on-chip decision sequence of small packets inbound to the on-chip decision
engine and sustain full interface rate for some reasonable engine and sustain full interface rate for some reasonable
average packet rate. Absent this small on-chip buffering, average packet rate. Absent this small on-chip buffering,
QoS agnostic packet drops can occur. QoS agnostic packet drops can occur.
See Section 2.3. See Section 2.3.
5. The implementer and system designer MUST support pseudowire 5. The implementations and system designs MUST support pseudowire
control word (CW) if MPLS-TP is supported or if ACH [RFC5586] is control word (CW) if MPLS-TP is supported or if ACH [RFC5586] is
being used on a pseudowire. The implementer and system designer being used on a pseudowire. The implementation and system design
SHOULD support pseudowire CW even if MPLS-TP and ACH [RFC5586] SHOULD support pseudowire CW even if MPLS-TP and ACH [RFC5586]
are not used, using instead CW and VCCV Type 1 [RFC5085] to allow are not used, using instead CW and VCCV Type 1 [RFC5085] to allow
the use of multipath in the underlying network topology without the use of multipath in the underlying network topology without
impacting the PW traffic. impacting the PW traffic. [RFC7079] does note that there are
[I-D.ietf-pwe3-vccv-impl-survey-results] does note that there are
still some deployments where the CW is not always used. It also still some deployments where the CW is not always used. It also
notes that many service providers do enable the CW. See notes that many service providers do enable the CW. See
Section 2.4.1 for more discussion on why deployments SHOULD Section 2.4.1 for more discussion on why deployments SHOULD
enable the pseudowire CW. enable the pseudowire CW.
6. The implementer and system designer SHOULD support adding a 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 pseudowire Flow Label [RFC6391]. Deployments MAY enable this
feature for appropriate pseudowire types. See Section 2.4.3. feature for appropriate pseudowire types. See Section 2.4.3.
7. The implementer and system designer SHOULD support adding an MPLS 2. The implementer and system designer SHOULD support adding an MPLS
entropy label [RFC6790]. Deployments MAY enable this feature. entropy label [RFC6790]. Deployments MAY enable this feature.
See Section 2.4.4. See Section 2.4.4.
1.4. Target Audience 1.4. Target Audience
This document is intended for multiple audiences: implementer This document is intended for multiple audiences: implementer
(implementing MPLS forwarding in silicon or in software); systems (implementing MPLS forwarding in silicon or in software); systems
designer (putting together a MPLS forwarding systems); deployer designer (putting together a MPLS forwarding systems); deployer
(running an MPLS network). These guidelines are intended to serve (running an MPLS network). These guidelines are intended to serve
the following purposes: the following purposes:
1. Explain what to do and what not to do when a deep label stack is 1. Explain what to do and what not to do when a deep label stack is
encountered. (audience: implementer) encountered. (audience: implementer)
2. Highlight pitfalls to look for when implementing an MPLS 2. Highlight pitfalls to look for when implementing an MPLS
skipping to change at page 11, line 14 skipping to change at page 11, line 24
removing any misconception that it was available for removing any misconception that it was available for
experimentation or could be ignored. experimentation or could be ignored.
4. ECN is supported by [RFC5129]. 4. ECN is supported by [RFC5129].
5. The MPLS G-ACh and GAL are defined in [RFC5586]. 5. The MPLS G-ACh and GAL are defined in [RFC5586].
6. [RFC5332] redefines the two data link layer codepoints for MPLS 6. [RFC5332] redefines the two data link layer codepoints for MPLS
packets. packets.
Tunneling encapsulations which may carry MPLS, such as MPLS in GRE, Tunneling encapsulations carrying MPLS, such as MPLS in IP [RFC4023],
L2TP, or LDP, are out of scope. MPLS in GRE [RFC4023], MPLS in L2TPv3 [RFC4817], or MPLS in UDP
[I-D.ietf-mpls-in-udp], are out of scope.
Other RFCs have implications to MPLS Forwarding and do not update Other RFCs have implications to MPLS Forwarding and do not update
RFC3032 or RFC3209, including: RFC3032 or RFC3209, including:
1. The pseudowire (PW) Associated Channel Header (ACH), defined by 1. The pseudowire (PW) Associated Channel Header (ACH), defined by
[RFC5085], later generalized by the MPLS G-ACh [RFC5586]. [RFC5085], later generalized by the MPLS G-ACh [RFC5586].
2. The entropy label indicator (ELI) and entropy label (EL) are 2. The entropy label indicator (ELI) and entropy label (EL) are
defined by [RFC6790]. defined by [RFC6790].
A few RFCs update RFC3209. Those that are listed as updating RFC3209 A few RFCs update RFC3209. Those that are listed as updating RFC3209
generally impact only RSVP-TE signaling. Forwarding is modified by generally impact only RSVP-TE signaling. Forwarding is modified by
major extension built upon RFC3209. major extension built upon RFC3209.
RFCs which impact forwarding are discussed in the following RFCs which impact forwarding are discussed in the following
subsections. subsections.
2.1.1. MPLS Special Purpose Labels 2.1.1. MPLS Special Purpose Labels
[RFC3032] specifies that label values 0-15 are special purpose labels [RFC3032] specifies that label values 0-15 are special purpose labels
with special meanings. Three values of NULL label are defined (two with special meanings. [I-D.ietf-mpls-special-purpose-labels]
of which are later updated by [RFC4182]) and a router-alert label is renamed these from the term "reserved labels" used in [RFC3032]
defined. The original intent was that special purpose labels, except "special purpose labels". Three values of NULL label are defined
the NULL labels, could be sent to the routing engine CPU rather than (two of which are later updated by [RFC4182]) and a router-alert
be processed in forwarding hardware. Hardware support is required by label is defined. The original intent was that special purpose
new RFCs such as those defining entropy label and OAM processed as a labels, except the NULL labels, could be sent to the routing engine
result of receiving a GAL. For new special purpose labels, some CPU rather than be processed in forwarding hardware. Hardware
accommodation is needed for LSR that will send the labels to a support is required by new RFCs such as those defining entropy label
general purpose CPU or other highly programmable hardware. For and OAM processed as a result of receiving a GAL. For new special
example, ELI will only be sent to LSR which have signaled support for purpose labels, some accommodation is needed for LSR that will send
[RFC6790] and high OAM packet rate must be negotiated among the labels to a general purpose CPU or other highly programmable
endpoints. hardware. For example, ELI will only be sent to LSR which have
signaled support for [RFC6790] and high OAM packet rate must be
negotiated among endpoints.
[RFC3429] reserves a label for ITU-T Y.1711, however Y.1711 does not [RFC3429] reserves a label for ITU-T Y.1711, however Y.1711 does not
work with multipath and its use is strongly discouraged. work with multipath and its use is strongly discouraged.
The current list of special purpose labels can be found on the The current list of special purpose labels can be found on the
"Multiprotocol Label Switching Architecture (MPLS) Label Values" "Multiprotocol Label Switching Architecture (MPLS) Label Values"
registry reachable at IANA's pages at http://www.iana.org. registry reachable at IANA's pages at [1].
[I-D.ietf-mpls-special-purpose-labels] introduces an IANA "Extended [I-D.ietf-mpls-special-purpose-labels] introduces an IANA "Extended
Special Purpose MPLS Label Values" registry and makes use of the Special Purpose MPLS Label Values" registry and makes use of the
"extension" label, label 15, to indicate that the next label is an "extension" label, label 15, to indicate that the next label is an
extended special purpose label and requires special handling. The extended special purpose label and requires special handling. The
range of only 16 values for special purpose labels allows a table to 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 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 available for use may have to be handled in some other way in the
unlikely event that in the future the range of currently reserved unlikely event that in the future the range of currently reserved
values 256-1048575 are used. If only the standards action range, values 256-1048575 are used. If only the standards action range,
skipping to change at page 14, line 40 skipping to change at page 14, line 46
which the Bypass LSP traverses. FRR is covered in Section 2.1.7. 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 LDP L2VPN, LDP IPVPN, BGP L2VPN, and BGP IPVPN added support for VPN
services that are deployed by the vast majority of service providers. services that are deployed by the vast majority of service providers.
These VPN services added yet another label, bringing the label stack These VPN services added yet another label, bringing the label stack
depth (when FRR is active) to four. depth (when FRR is active) to four.
Pseudowires and VPN are discussed in further detail in Section 2.1.8 Pseudowires and VPN are discussed in further detail in Section 2.1.8
and Section 2.1.9. and Section 2.1.9.
MPLS hierarchy as described in [RFC4206] can in principle add up to MPLS hierarchy as described in [RFC4206] and updated by [RFC7074] can
four additional labels. MPLS hierarchy is discussed in in principle add at least one additional label. MPLS hierarchy is
Section 2.1.6. discussed in Section 2.1.6.
Other features such as Entropy Label (discussed in Section 2.4.4) and 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 Flow Label (discussed in Section 2.4.3) can add additional labels to
the label stack. the label stack.
Although theoretical scenarios can easily result in eight or more Although theoretical scenarios can easily result in eight or more
labels, such cases are rare if they occur at all today. For the 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 purpose of forwarding, only the top label needs to be examined if PHP
is used, a few more if UHP is used (see Section 2.5). For deep label is used, 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 stacks, quite a few labels may have to be examined for the purpose of
skipping to change at page 15, line 18 skipping to change at page 15, line 28
MPLS Link Bundling was the first RFC to address the need for multiple MPLS Link Bundling was the first RFC to address the need for multiple
parallel links between nodes [RFC4201]. MPLS Link Bundling is parallel links between nodes [RFC4201]. MPLS Link Bundling is
notable in that it tried not to change MPLS forwarding, except in notable in that it tried not to change MPLS forwarding, except in
specifying the "All-Ones" component link. MPLS Link Bundling is specifying the "All-Ones" component link. MPLS Link Bundling is
seldom if ever deployed. Instead multipath techniques described in seldom if ever deployed. Instead multipath techniques described in
Section 2.4 are used. Section 2.4 are used.
2.1.6. MPLS Hierarchy 2.1.6. MPLS Hierarchy
MPLS hierarchy is defined in [RFC4206]. Although RFC4206 is MPLS hierarchy is defined in [RFC4206] and updated by [RFC7074].
considered part of GMPLS, the Packet Switching Capable (PSC) portion Although RFC4206 is considered part of GMPLS, the Packet Switching
of the MPLS hierarchy are applicable to MPLS and may be supported in Capable (PSC) portion of the MPLS hierarchy are applicable to MPLS
an otherwise GMPLS free implementation. The MPLS PSC hierarchy and may be supported in an otherwise GMPLS free implementation. The
remains the most likely means of providing further scaling in an MPLS PSC hierarchy remains the most likely means of providing further
RSVP-TE MPLS network, particularly where the network is designed to scaling in an RSVP-TE MPLS network, particularly where the network is
provide RSVP-TE connectivity to the edges. This is the case for designed to provide RSVP-TE connectivity to the edges. This is the
envisioned MPLS-TP networks. The use of the MPLS PSC hierarchy can case for envisioned MPLS-TP networks. The use of the MPLS PSC
add as many as four labels to a label stack, though it is likely that hierarchy can add at least one additional label to a label stack,
only one layer of PSC will be used in the near future. though it is likely that only one layer of PSC will be used in the
near future.
2.1.7. MPLS Fast Reroute (FRR) 2.1.7. MPLS Fast Reroute (FRR)
Fast reroute is defined by [RFC4090]. Two significantly different Fast reroute is defined by [RFC4090]. Two significantly different
methods are defined in RFC4090, the "One-to-One Backup" method which methods are defined in RFC4090, the "One-to-One Backup" method which
uses the "Detour LSP" and the " Facility Backup" which uses a "bypass uses the "Detour LSP" and the " Facility Backup" which uses a "bypass
tunnel". These are commonly referred to as the detour and bypass tunnel". These are commonly referred to as the detour and bypass
methods respectively. methods respectively.
The detour method makes use of a presignaled LSP. Hardware The detour method makes use of a presignaled LSP. Hardware
skipping to change at page 17, line 11 skipping to change at page 17, line 23
jitter must be bounded, a jitter buffer is always necessary. The jitter must be bounded, a jitter buffer is always necessary. The
jitter buffer is needed regardless of whether reordering is done. In jitter buffer is needed regardless of whether reordering is done. In
order to be effective, a reorder buffer must often be larger than a order to be effective, a reorder buffer must often be larger than a
jitter buffer needs to be creating a tradeoff between reducing loss jitter buffer needs to be creating a tradeoff between reducing loss
and minimizing delay. and minimizing delay.
PW services which are not timing critical bit streams in nature are PW services which are not timing critical bit streams in nature are
cell oriented or frame oriented. Though resequencing support may be cell oriented or frame oriented. Though resequencing support may be
beneficial to PW cell and frame oriented payloads such as ATM, FR and beneficial to PW cell and frame oriented payloads such as ATM, FR and
Ethernet, this support is desirable but not required. Requirements Ethernet, this support is desirable but not required. Requirements
to hamdle out of order packets at all vary among services and to handle out of order packets at all vary among services and
deployments. For example for Ethernet PW, occasional (very rare) deployments. For example for Ethernet PW, occasional (very rare)
reordering is usually acceptable. If the Ethernet PW is carrying reordering is usually acceptable. If the Ethernet PW is carrying
MPLS-TP, then this reordering may be acceptable. MPLS-TP, then this reordering may be acceptable.
Reducing jitter is best done by an end-system, given that the Reducing jitter is best done by an end-system, given that the
tradeoff of loss vs delay varies among services. For example with tradeoff of loss vs delay varies among services. For example with
interactive real time services low delay is preferred, while with interactive real time services low delay is preferred, while with
non-interactive (one way) real time services low loss is preferred. non-interactive (one way) real time services low loss is preferred.
The same end-site may be receiving both types of traffic. Regardless The same end-site may be receiving both types of traffic. Regardless
of this, bounded jitter is sometimes a requiremnet for specific of this, bounded jitter is sometimes a requirement for specific
deployments. deployments.
Packet reorder should be rare except in a small number of Packet reorder should be rare except in a small number of
circumstances, most of which are due to network design or equipment circumstances, most of which are due to network design or equipment
design errors: design errors:
1. The most common case is where reordering occurs is rare, 1. The most common case is where reordering is rare, occurring only
occurring only when a network or equipment fault forces traffic when a network or equipment fault forces traffic on a new path
on a new path with different delay. The packet loss that with different delay. The packet loss that accompanies a network
accompanies a network or equipment fault is generally more or equipment fault is generally more disruptive than any
disruptive than any reordering which may occur. reordering which may occur.
2. A path change can be caused by reasons other than a network or 2. A path change can be caused by reasons other than a network or
equipment fault, such as administrative routing change. This may equipment fault, such as administrative routing change. This may
result in packet reordering but generally without any packet result in packet reordering but generally without any packet
loss. loss.
3. If the edge is not using pseudowire control word (CW) and the 3. If the edge is not using pseudowire control word (CW) and the
core is using multipath, reordering will be far more common. If core is using multipath, reordering will be far more common. If
this is occurring, the best solution is to use CW on the edge, this is occurring, using CW on the edge will solve the problem.
rather than try to fix the reordering using resequencing. 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 4. Another avoidable case is where some core equipment has multipath
and for some reason insists on periodically installing a new and for some reason insists on periodically installing a new
random number as the multipath hash seed. If supporting MPLS-TP, random number as the multipath hash seed. If supporting MPLS-TP,
equipment MUST provide a means to disable periodic hash reseeding equipment MUST provide a means to disable periodic hash reseeding
and deployments MUST disable periodic hash reseeding. Even if and deployments MUST disable periodic hash reseeding. Operator
not supporting MPLS-TP, equipment should provide a means to experience dictates that even if not supporting MPLS-TP,
disable periodic hash reseeding and deployments should disable equipment SHOULD provide a means to disable periodic hash
periodic hash reseeding. reseeding and deployments SHOULD disable periodic hash reseeding.
In provider networks which use multipath techniques and which may In provider networks which use multipath techniques and which may
occassionally rebalance traffic or which may change PW paths occasionally rebalance traffic or which may change PW paths
occasionally for other reasons, reordering may be far more common occasionally for other reasons, reordering may be far more common
than loss. Where reordering is more common than loss, resequencing than loss. Where reordering is more common than loss, resequencing
packets is beneficial, rather than dropping packets at egress when packets is beneficial, rather than dropping packets at egress when
out of order arrival occus. Resequencing is most important for PW out of order arrival occurs. Resequencing is most important for PW
payload types with a high expectation of lossless delivery since in payload types with a high expectation of lossless delivery since in
such cases out of order delivery within the network results in PW such cases out of order delivery within the network results in PW
loss. loss.
2.1.9. Layer-2 and Layer-3 VPN 2.1.9. Layer-2 and Layer-3 VPN
Layer-2 VPN [RFC4664] and Layer-3 VPN [RFC4110] add one or more label 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 entry to the MPLS label stack. VPN encapsulations are out of scope
for this document. Its impact on forwarding at midpoint LSR are for this document. Its impact on forwarding at midpoint LSR are
within scope. within scope.
skipping to change at page 19, line 17 skipping to change at page 19, line 31
If packet replication is performed at LSR ingress, then the ingress If packet replication is performed at LSR ingress, then the ingress
interface performance may suffer. If the packet replication is interface performance may suffer. If the packet replication is
performed within a LSR switching fabric and at LSR egress, congestion performed within a LSR switching fabric and at LSR egress, congestion
of egress interfaces cannot make use of backpressure to ingress of egress interfaces cannot make use of backpressure to ingress
interfaces using techniques such as virtual output queuing (VOQ). If interfaces using techniques such as virtual output queuing (VOQ). If
buffering is primarily supported at egress, then the need for buffering is primarily supported at egress, then the need for
backpressure is minimized. There may be no good solution for high backpressure is minimized. There may be no good solution for high
volumes of multicast traffic if VOQ is used. 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 LSP differ in that any branch may provide an input, including a MP2MP LSP differ in that any branch may provide an input, including a
leaf. Packets must be replicated onto all other branches. This leaf. Packets must be replicated onto all other branches. This
forwarding is often implemented as multiple P2MP forwarding trees, forwarding is often implemented as multiple P2MP forwarding trees,
one for each potential input interface at a given LSR. one for each potential input interface at a given LSR.
2.3. Packet Rates 2.3. Packet Rates
While average packet size of Internet traffic may be large, long While average packet size of Internet traffic may be large, long
sequences of small packets have both been predicted in theory and sequences of small packets have both been predicted in theory and
observed in practice. Traffic compression and TCP ACK compression observed in practice. Traffic compression and TCP ACK compression
can conspire to create long sequences of packets of 40-44 bytes in can conspire to create long sequences of packets of 40-44 bytes in
payload length. If carried over Ethernet, the 64 byte minimum payload length. If carried over Ethernet, the 64 byte minimum
payload applies, yielding a packet rate of approximately 150 Mpps payload applies, yielding a packet rate of approximately 150 Mpps
(million packets per second) for the duration of the burst on a (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 nominal 100 Gb/s link. The peak rate for other encapsulations can be
as high as 250 Mpps (for example IP or MPLS encapsulated using GFP as high as 250 Mpps (for example IP or MPLS encapsulated using GFP
over OTN ODU4). over OTN ODU4).
It is possible that the packet rates achieved by a specific It is possible that the packet rates achieved by a specific
implementation is acceptable for a minimum payload size, such as 64 implementation is acceptable for a minimum payload size, such as 64
byte (64B) payload for Ethernet, but the acheived rate declines to an byte (64B) payload for Ethernet, but the achieved rate declines to an
unacceptable level for other packet sizes, such as 65B payload. unacceptable level for other packet sizes, such as 65B payload.
There are other packet rates of interest besides TCP ACK. For There are other packet rates of interest besides TCP ACK. For
example, a TCP ACK carried over an Ethernet PW over MPLS over 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 Ethernet may occupy 82B or 82B plus an increment of 4B if additional
MPLS labels are present. MPLS labels are present.
A graph of packet rate vs. packet size often displays a sawtooth. A graph of packet rate vs. packet size often displays a sawtooth.
The sawtooth is commonly due to a memory bottleneck and memory The sawtooth is commonly due to a memory bottleneck and memory
widths, sometimes internal cache, but often a very wide external widths, sometimes internal cache, but often a very wide external
buffer memory interface. In some cases it may be due to a fabric buffer memory interface. In some cases it may be due to a fabric
skipping to change at page 21, line 29 skipping to change at page 21, line 44
packet decision engine to accommodate long bursts of small packet decision engine to accommodate long bursts of small
packets. packets.
2.4. MPLS Multipath Techniques 2.4. MPLS Multipath Techniques
In any large provider, service providers and content providers, hash In any large provider, service providers and content providers, hash
based multipath techniques are used in the core and in the edge. In 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 many of these providers hash based multipath is also used in the
larger metro networks. larger metro networks.
The Differentiated Services requirements for good reasons 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 or path change for load balancing or path change for
other reason.
The most common multipath techniques are ECMP applied at the IP The most common multipath techniques are ECMP applied at the IP
forwarding level, Ethernet LAG with inspection of the IP payload, and forwarding level, Ethernet LAG with inspection of the IP payload, and
multipath on links carrying both IP and MPLS, where the IP header is multipath on links carrying both IP and MPLS, where the IP header is
inspected below the MPLS label stack. In most core networks, the inspected below the MPLS label stack. In most core networks, the
vast majority of traffic is MPLS encapsulated. vast majority of traffic is MPLS encapsulated.
In order to support an adequately balanced load distribution across In order to support an adequately balanced load distribution across
multiple links, IP header information must be used. Common practice multiple links, IP header information must be used. Common practice
today is to reinspect the IP headers at each LSR and use the label 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. stack and IP header information in a hash performed at each LSR.
skipping to change at page 24, line 33 skipping to change at page 25, line 8
used and label entries below that label SHOULD NOT be used and used and label entries below that label SHOULD NOT be used and
the MPLS payload SHOULD NOT be used. See below this list for the MPLS payload SHOULD NOT be used. See below this list for
reasons. reasons.
3. Special purpose labels (label values 0-15) MUST NOT be used. 3. Special purpose labels (label values 0-15) MUST NOT be used.
Extended special purpose labels (any label following label 15) Extended special purpose labels (any label following label 15)
MUST NOT be used. In particular, GAL and RA MUST NOT be used so 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 that OAM traffic follows the same path as payload packets with
the same label stack. the same label stack.
4. The most entropy is generally found in the label stack entries 4. If a new special purpose label or extended special purpose label
is defined which 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 near the bottom of the label stack (innermost label, closest to
S=1 bit). If the entire label stack cannot be used (or entire 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 stack up to an EL), then it is better to use as many labels as
possible closest to the bottom of stack. possible closest to the bottom of stack.
5. If no ELI is encountered, and the first nibble of payload 6. If no ELI is encountered, and the first nibble of payload
contains a 4 (IPv4) or 6 (IPv6), an implementation SHOULD support contains a 4 (IPv4) or 6 (IPv6), an implementation SHOULD support
the ability to interpret the payload as IPv4 or IPv6 and extract the ability to interpret the payload as IPv4 or IPv6 and extract
and use appropriate fields from the IP headers. This feature is and use appropriate fields from the IP headers. This feature is
considered a hard requirement by many service providers. If considered a hard requirement by many service providers. If
supported, there MUST be a way to disable it (if, for example, PW supported, there MUST be a way to disable it (if, for example, PW
without CW are used). This ability to disable this feature is without CW are used). This ability to disable this feature is
considered a hard requirement by many service providers. considered a hard requirement by many service providers.
Therefore an implementation has a very strong incentive to Therefore an implementation has a very strong incentive to
support both options. support both options.
6. A label which is popped at egress (UHP pop) SHOULD NOT be used. 7. A label which is popped at egress (UHP pop) SHOULD NOT be used.
A label which is popped at the penultimate hop (PHP pop) SHOULD A label which is popped at the penultimate hop (PHP pop) SHOULD
be used. be used.
Apparently some chips have made use of the TC (formerly EXP) bits as 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 a source of entropy. This is very harmful since it will reorder
Assured Forwarding (AF) traffic [RFC2597] when a subset does not Assured Forwarding (AF) traffic [RFC2597] when a subset does not
conform to the configured rates and is remarked but not dropped at a conform to the configured rates and is remarked but not dropped at a
prior LSR. Traffic which uses MPLS ECN [RFC5129] can also be prior LSR. Traffic which uses MPLS ECN [RFC5129] can also be
reordered if TC is used for entropy. Therefore, as stated in the reordered if TC is used for entropy. Therefore, as stated in the
guidelines above, the TC field (formerly EXP) MUST NOT be used in guidelines above, the TC field (formerly EXP) MUST NOT be used in
skipping to change at page 26, line 36 skipping to change at page 27, line 21
UDP port numbers are not at fixed offsets. UDP port numbers are not at fixed offsets.
4. The IPv6 header flow field SHOULD be used. This is the explicit 4. The IPv6 header flow field SHOULD be used. This is the explicit
purpose of the IPv6 flow field, however observed flow fields purpose of the IPv6 flow field, however observed flow fields
rarely contains a non-zero value. Some uses of the flow field rarely contains a non-zero value. Some uses of the flow field
have been defined such as [RFC6438]. In the absence of MPLS have been defined such as [RFC6438]. In the absence of MPLS
encapsulation, the IPv6 flow field can serve a role equivalent to encapsulation, the IPv6 flow field can serve a role equivalent to
entropy label. entropy label.
5. Support for other protocols that share a common Layer-4 header 5. Support for other protocols that share a common Layer-4 header
such as RTP, UDP-lite, SCTP and DCCP SHOULD be provided, such as RTP [RFC3550], UDP-Lite [RFC3828], SCTP [RFC4960] and
particularly for edge or access equipment where additional DCCP [RFC4340] SHOULD be provided, particularly for edge or
entropy may be needed. Equipment SHOULD also use RTP, UDP-lite, access equipment where additional entropy may be needed.
SCTP and DCCP headers when creating an entropy label. 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: 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 a. Similar to avoiding TC in MPLS, the IP DSCP, and ECN bits
MUST NOT be used. MUST NOT be used.
b. The IPv4 TTL or IPv6 Hop Count SHOULD NOT be used. b. The IPv4 TTL or IPv6 Hop Count SHOULD NOT be used.
c. Note that the IP TOS field was deprecated ([RFC0791] was c. Note that the IP TOS field was deprecated ([RFC0791] was
updated by [RFC2474]). No part of the IP DSCP field can be updated by [RFC2474]). No part of the IP DSCP field can be
used (formerly IP PREC and IP TOS bits). used (formerly IP PREC and IP TOS bits).
7. Some IP encapsulations support tunneling, such as IP-in-IP, GRE, 7. Some IP encapsulations support tunneling, such as IP-in-IP, GRE,
L2TPv3, and IPSEC. These provide a greater source of entropy L2TPv3, and IPSEC. These provide a greater source of entropy
which some provider networks carrying large amounts of tunneled which some provider networks carrying large amounts of tunneled
traffic may need. The use of tunneling header information is out traffic may need, for example as used in [RFC5640] for GRE and
of scope for this document. L2TPv3. The use of tunneling header information is out of scope
for this document.
This document makes the following recommendations. These This document makes the following recommendations. These
recommendations are not required to claim compliance to any existing recommendations are not required to claim compliance to any existing
RFC therefore implementers are free to ignore them, but due to RFC therefore implementers are free to ignore them, but due to
service provider requirements should consider the risk of doing so. service provider requirements should consider the risk of doing so.
The use of IP addresses MUST be supported and TCP and UDP ports The use of IP addresses MUST be supported and TCP and UDP ports
(conditional on the protocol field and properly located) MUST be (conditional on the protocol field and properly located) MUST be
supported. The ability to disable use of UDP and TCP ports 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 available. Though potentially very useful in some networks, it is
uncommon to support using payloads of tunneling protocols carried uncommon to support using payloads of tunneling protocols carried
skipping to change at page 33, line 29 skipping to change at page 34, line 18
BFD and LSP Ping. BFD and LSP Ping.
CC-CV and alarm reporting is tied to protection and therefore SHOULD CC-CV and alarm reporting is tied to protection and therefore SHOULD
be supported in forwarding hardware in order to provide protection be supported in forwarding hardware in order to provide protection
for a large number of affected LSP within target response intervals. for a large number of affected LSP within target response intervals.
Since CC-CV is supported by BFD, for MPLS-TP providing hardware Since CC-CV is supported by BFD, for MPLS-TP providing hardware
assistance for BFD processing helps insure that protection recovery assistance for BFD processing helps insure that protection recovery
time requirements can be met even for faults affecting a large number time requirements can be met even for faults affecting a large number
of LSP. of LSP.
MPLS-TP Protection State Coordination (PSC) is defined by [RFC6378]
and updated by [I-D.ietf-mpls-psc-updates], correcting some errors in
[RFC6378].
2.6.5. MPLS OAM and Layer-2 OAM Interworking 2.6.5. MPLS OAM and Layer-2 OAM Interworking
[RFC6670] provides the reasons for selecting a single MPLS-TP OAM [RFC6670] provides the reasons for selecting a single MPLS-TP OAM
solution and examines the consequences were ITU-T to develop a second solution and examines the consequences were ITU-T to develop a second
OAM solution that is based on Ethernet encodings and mechanisms. OAM solution that is based on Ethernet encodings and mechanisms.
[RFC6310] and [RFC7023] specifies the mapping of defect states [RFC6310] and [RFC7023] specifies the mapping of defect states
between many types of hardware Attachment Circuits (ACs) and between many types of hardware Attachment Circuits (ACs) and
associated Pseudowires (PWs). This functionality SHOULD be supported associated Pseudowires (PWs). This functionality SHOULD be supported
in forwarding hardware. in forwarding hardware.
skipping to change at page 34, line 28 skipping to change at page 35, line 28
in dedicated forwarding hardware. Examples include packet and byte in dedicated forwarding hardware. Examples include packet and byte
counters needed for LM OAM as well as needed for management counters needed for LM OAM as well as needed for management
protocols. Similarly the capture and insertion of packet and byte protocols. Similarly the capture and insertion of packet and byte
counts or timestamps needed for transmitted LM or DM or time counts or timestamps needed for transmitted LM or DM or time
synchronization packets MUST be implemented in forwarding hardware if synchronization packets MUST be implemented in forwarding hardware if
high accuracy is required. high accuracy is required.
For some functions there is a strong case to provide limited support For some functions there is a strong case to provide limited support
in forwarding hardware but may make use of an external general in forwarding hardware but may make use of an external general
purpose processor if performance criteria can be met. For example purpose processor if performance criteria can be met. For example
origination of RDI triggered by CC-CV, response to RDI, and PSC origination of RDI triggered by CC-CV, response to RDI, and
functionality may be supported by hardware, but expansion to a large Protection State Coordination (PSC) functionality may be supported by
number of client LSP and transmission of AIS or RDI to the client LSP hardware, but expansion to a large number of client LSP and
may occur in a general purpose processor. Some forwarding hardware transmission of AIS or RDI to the client LSP may occur in a general
supports one or more on-chip general purpose processors which may be purpose processor. Some forwarding hardware supports one or more on-
well suited for such a role. chip general purpose processors which may be well suited for such a
role. [I-D.ietf-mpls-psc-updates], being 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, The customer (system supplier or provider) should not dictate design,
but should independently validate target functionality and but should independently validate target functionality and
performance. However, it is not uncommon for service providers and performance. However, it is not uncommon for service providers and
system implementers to insist on reviewing design details (under NDA) system implementers to insist on reviewing design details (under NDA)
due to past experiences with suppliers and to reject suppliers who due to past experiences with suppliers and to reject suppliers who
are unwilling to provide details. are unwilling to provide details.
2.7. Number and Size of Flows 2.7. Number and Size of Flows
Service provider networks may carry up to hundreds of millions of 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 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 a second. A subset of the flows are low capacity and somewhat long
lived. When Internet traffic dominates capacity a very small subset lived. When Internet traffic dominates capacity a very small subset
of flows are high capacity and/or very long lived. of flows are high capacity and/or very long lived.
Two types of limitations with regard to number and size of flows have Two types of limitations with regard to number and size of flows have
been observed. been observed.
1. Some hardware cannot handle some very large flows because of 1. Some hardware cannot handle some very large flows because of
skipping to change at page 36, line 28 skipping to change at page 37, line 38
Q#7 Is MPLS hierarchy supported? Q#7 Is MPLS hierarchy supported?
a. Are both PHP and UHP supported? What limitations exist on a. Are both PHP and UHP supported? What limitations exist on
the number of pop operations with UHP? the number of pop operations with UHP?
b. Are the pipe, short-pipe, and uniform models supported? Are b. Are the pipe, short-pipe, and uniform models supported? Are
TTL and TC values updated correctly at egress where TTL and TC values updated correctly at egress where
applicable? applicable?
See Section 2.1.6 See Section 2.1.6 regarding MPLS hierarchy. See [RFC3443]
regarding PHP, UHP, and pipe, short-pipe, and uniform models.
Q#8 Are pseudowire sequence numbers handled correctly? See Q#8 Are pseudowire sequence numbers handled correctly? See
Section 2.1.8.1. Section 2.1.8.1.
Q#9 Is VPN LER functionality handled correctly and without Q#9 Is VPN LER functionality handled correctly and without
performance issues? See Section 2.1.9. performance issues? See Section 2.1.9.
Q#10 Is MPLS multicast (P2MP and MP2MP) handled correctly? Q#10 Is MPLS multicast (P2MP and MP2MP) handled correctly?
a. Are packets dropped on uncongested outputs if some outputs a. Are packets dropped on uncongested outputs if some outputs
skipping to change at page 44, line 15 skipping to change at page 45, line 23
T#28 Verify LSP Ping and LSP Traceroute capability. T#28 Verify LSP Ping and LSP Traceroute capability.
T#29 Determine maximum rates of MPLS-TP CC-CV traffic. If CC-CV T#29 Determine maximum rates of MPLS-TP CC-CV traffic. If CC-CV
requires CPU intervention, determine both maximum rates and CPU requires CPU intervention, determine both maximum rates and CPU
loading when multiple interfaces are active. loading when multiple interfaces are active.
T#30 Determine MPLS-TP DM precision. T#30 Determine MPLS-TP DM precision.
T#31 Determine MPLS-TP LM accuracy. T#31 Determine MPLS-TP LM accuracy.
T#32 Verify MPLS-TP AIS/RDI and PSC functionality, protection speed, T#32 Verify MPLS-TP AIS/RDI and Protection State Coordination (PSC)
and AIS/RDI notification speed when a large number of Management functionality, protection speed, and AIS/RDI notification speed
Entities (ME) must be notified with AIS/RDI. when a large number of Management Entities (ME) must be notified
with AIS/RDI.
5. Acknowledgements 5. Acknowledgements
Numerous very useful comments have been received in private email. Numerous very useful comments have been received in private email.
Some of these contributions are acknowledged here, approximately in Some of these contributions are acknowledged here, approximately in
chronologic order. chronologic order.
Paul Doolan provided a brief review resulting in a number of Paul Doolan provided a brief review resulting in a number of
clarifications, most notably regarding on-chip vs. system buffering, clarifications, most notably regarding on-chip vs. system buffering,
100 Gb/s link speed assumptions in the 150 Mpps figure, and handling 100 Gb/s link speed assumptions in the 150 Mpps figure, and handling
skipping to change at page 44, line 43 skipping to change at page 46, line 5
Valuable comments were received on the BMWG mailing list. Jay Valuable comments were received on the BMWG mailing list. Jay
Karthik pointed out testing methodology hints that after discussion Karthik pointed out testing methodology hints that after discussion
were deemed out of scope and were removed but may benefit later work were deemed out of scope and were removed but may benefit later work
in BMWG. in BMWG.
Nabil Bitar pointed out the need to cover QoS (Differentiated Nabil Bitar pointed out the need to cover QoS (Differentiated
Services), MPLS multicast (P2MP and MP2MP), and MPLS-TP OAM. Nabil Services), MPLS multicast (P2MP and MP2MP), and MPLS-TP OAM. Nabil
also provided a number of clarifications to the questions and tests also provided a number of clarifications to the questions and tests
in Section 3 and Section 4. in Section 3 and Section 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 Gregory Mirsky and Thomas Beckhaus provided useful comments during
the MPLS RT review. the MPLS RT review.
Tal Mizrahi provided comments that prompted clarifications regarding Tal Mizrahi provided comments that prompted clarifications regarding
timestamp processing, local delivery of packets, and the need for timestamp processing, local delivery of packets, and the need for
hardware assistance in processing OAM traffic. hardware assistance in processing OAM traffic.
Alexander (Sasha) Vainshtein pointed out errors in Section 2.1.8.1 Alexander (Sasha) Vainshtein pointed out errors in Section 2.1.8.1
and suggested new text which after lengthy discussion resulted in and suggested new text which after lengthy discussion resulted in
restating the sumarization of requirements from PWE3 RFCs and more restating the summarization of requirements from PWE3 RFCs and more
clearly stating the benefits and drawbacks of packet resequencing clearly stating the benefits and drawbacks of packet resequencing
based on PW sequence number. 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.
6. IANA Considerations 6. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
7. Security Considerations 7. Security Considerations
This document reviews forwarding behavior specified elsewhere and This document reviews forwarding behavior specified elsewhere and
points out compliance and performance requirements. As such it points out compliance and performance requirements. As such it
introduces no new security requirements or concerns. introduces no new security requirements or concerns.
Some advice on hardware support and other equipment hardening against
DoS attack can be found in Section 4.6.
Knowledge of potential performance shortcomings may serve to help new Knowledge of potential performance shortcomings may serve to help new
implementations avoid pitfalls. It is unlikely that such knowledge implementations avoid pitfalls. It is unlikely that such knowledge
could be the basis of new denial of service as these pitfalls are could be the basis of new denial of service as these pitfalls are
already widely known in the service provider community and among already widely known in the service provider community and among
leading equipment suppliers. In practice extreme data and packet leading equipment suppliers. In practice extreme data and packet
rate are needed to affect existing equipment and to affect networks rate are needed to affect existing equipment and to affect networks
that may be still vulnerable due to failure to implement adequate that may be still vulnerable due to failure to implement adequate
protection. The extreme data and packet rates make this type of protection. The extreme data and packet rates make this type of
denial of service unlikely and make undetectable denial of service of denial of service unlikely and make undetectable denial of service of
this type impossible. this type impossible.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-mpls-psc-updates]
Osborne, E., "Updates to PSC", draft-ietf-mpls-psc-
updates-01 (work in progress), October 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001. Encoding", RFC 3032, January 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
skipping to change at page 46, line 19 skipping to change at page 47, line 43
[RFC4182] Rosen, E., "Removing a Restriction on the use of MPLS [RFC4182] Rosen, E., "Removing a Restriction on the use of MPLS
Explicit NULL", RFC 4182, September 2005. Explicit NULL", RFC 4182, September 2005.
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, February 2006. 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 [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion
Marking in MPLS", RFC 5129, January 2008. 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 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
Associated Channel", RFC 5586, June 2009. Associated Channel", RFC 5586, June 2009.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, June 2010.
[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, [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan,
J., and S. Amante, "Flow-Aware Transport of Pseudowires J., and S. Amante, "Flow-Aware Transport of Pseudowires
over an MPLS Packet Switched Network", RFC 6391, November over an MPLS Packet Switched Network", RFC 6391, November
2011. 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.
[RFC6720] Pignataro, C. and R. Asati, "The Generalized TTL Security
Mechanism (GTSM) for the Label Distribution Protocol
(LDP)", RFC 6720, August 2012.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding", L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, November 2012. RFC 6790, November 2012.
8.2. Informative References 8.2. Informative References
[ACK-compression] [ACK-compression]
, , , "Observations and Dynamics of a Congestion Control , , , "Observations and Dynamics of a Congestion Control
Algorithm: The Effects of Two-Way Traffic", Proc. ACM Algorithm: The Effects of Two-Way Traffic", Proc. ACM
SIGCOMM, ACM Computer Communications Review (CCR) Vol 21, SIGCOMM, ACM Computer Communications Review (CCR) Vol 21,
No 4, 1991, pp.133-147., 1991. No 4, 1991, pp.133-147., 1991.
[I-D.ietf-mpls-in-udp]
Building, K., Sheth, N., Yong, L., Pignataro, C., and F.
Yongbing, "Encapsulating MPLS in UDP", draft-ietf-mpls-in-
udp-05 (work in progress), December 2013.
[I-D.ietf-mpls-special-purpose-labels] [I-D.ietf-mpls-special-purpose-labels]
Kompella, K., Andersson, L., and A. Farrel, "Allocating Kompella, K., Andersson, L., and A. Farrel, "Allocating
and Retiring Special Purpose MPLS Labels", draft-ietf- and Retiring Special Purpose MPLS Labels", draft-ietf-
mpls-special-purpose-labels-03 (work in progress), July mpls-special-purpose-labels-03 (work in progress), July
2013. 2013.
[I-D.ietf-pwe3-vccv-impl-survey-results]
Malis, A., "The Pseudowire (PW) & Virtual Circuit
Connectivity Verification (VCCV) Implementation Survey
Results", draft-ietf-pwe3-vccv-impl-survey-results-03
(work in progress), October 2013.
[I-D.ietf-tictoc-1588overmpls] [I-D.ietf-tictoc-1588overmpls]
Davari, S., Oren, A., Bhatia, M., Roberts, P., and L. Davari, S., Oren, A., Bhatia, M., Roberts, P., and L.
Montini, "Transporting Timing messages over MPLS Montini, "Transporting Timing messages over MPLS
Networks", draft-ietf-tictoc-1588overmpls-05 (work in Networks", draft-ietf-tictoc-1588overmpls-05 (work in
progress), June 2013. progress), June 2013.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981. 1981.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
skipping to change at page 47, line 42 skipping to change at page 50, line 28
[RFC3429] Ohta, H., "Assignment of the 'OAM Alert Label' for [RFC3429] Ohta, H., "Assignment of the 'OAM Alert Label' for
Multiprotocol Label Switching Architecture (MPLS) Multiprotocol Label Switching Architecture (MPLS)
Operation and Maintenance (OAM) Functions", RFC 3429, Operation and Maintenance (OAM) Functions", RFC 3429,
November 2002. November 2002.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471, (GMPLS) Signaling Functional Description", RFC 3471,
January 2003. 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- [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
Edge (PWE3) Architecture", RFC 3985, March 2005. 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 [RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3
Provider-Provisioned Virtual Private Networks (PPVPNs)", Provider-Provisioned Virtual Private Networks (PPVPNs)",
RFC 4110, July 2005. RFC 4110, July 2005.
[RFC4124] Le Faucheur, F., "Protocol Extensions for Support of [RFC4124] Le Faucheur, F., "Protocol Extensions for Support of
Diffserv-aware MPLS Traffic Engineering", RFC 4124, June Diffserv-aware MPLS Traffic Engineering", RFC 4124, June
2005. 2005.
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4221] Nadeau, T., Srinivasan, C., and A. Farrel, "Multiprotocol [RFC4221] Nadeau, T., Srinivasan, C., and A. Farrel, "Multiprotocol
Label Switching (MPLS) Management Overview", RFC 4221, Label Switching (MPLS) Management Overview", RFC 4221,
November 2005. November 2005.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. [RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S.
Matsushima, "Operations and Management (OAM) Requirements Matsushima, "Operations and Management (OAM) Requirements
for Multi-Protocol Label Switched (MPLS) Networks", RFC for Multi-Protocol Label Switched (MPLS) Networks", RFC
4377, February 2006. 4377, February 2006.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379, Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006. February 2006.
[RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual [RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual
Private Networks (L2VPNs)", RFC 4664, September 2006. 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, [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
"Extensions to Resource Reservation Protocol - Traffic "Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007. Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal
Cost Multipath Treatment in MPLS Networks", BCP 128, RFC Cost Multipath Treatment in MPLS Networks", BCP 128, RFC
4928, June 2007. 4928, June 2007.
[RFC4950] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC
Extensions for Multiprotocol Label Switching", RFC 4950, 4960, September 2007.
August 2007.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007. Specification", RFC 5036, October 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.
[RFC5317] Bryant, S. and L. Andersson, "Joint Working Team (JWT) [RFC5317] Bryant, S. and L. Andersson, "Joint Working Team (JWT)
Report on MPLS Architectural Considerations for a Report on MPLS Architectural Considerations for a
Transport Profile", RFC 5317, February 2009. Transport Profile", RFC 5317, February 2009.
[RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS
Multicast Encapsulations", RFC 5332, August 2008.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", RFC 5462, February 2009. Class" Field", RFC 5462, February 2009.
[RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load-
Balancing for Mesh Softwires", RFC 5640, August 2009.
[RFC5695] Akhter, A., Asati, R., and C. Pignataro, "MPLS Forwarding [RFC5695] Akhter, A., Asati, R., and C. Pignataro, "MPLS Forwarding
Benchmarking Methodology for IP Flows", RFC 5695, November Benchmarking Methodology for IP Flows", RFC 5695, November
2009. 2009.
[RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for [RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for
Operations, Administration, and Maintenance (OAM) in MPLS Operations, Administration, and Maintenance (OAM) in MPLS
Transport Networks", RFC 5860, May 2010. Transport Networks", RFC 5860, May 2010.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, June 2010.
[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.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
Time Protocol Version 4: Protocol and Algorithms Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010. Specification", RFC 5905, June 2010.
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
D., and S. Mansfield, "Guidelines for the Use of the "OAM" D., and S. Mansfield, "Guidelines for the Use of the "OAM"
Acronym in the IETF", BCP 161, RFC 6291, June 2011. Acronym in the IETF", BCP 161, RFC 6291, June 2011.
[RFC6310] Aissaoui, M., Busschbach, P., Martini, L., Morrow, M., [RFC6310] Aissaoui, M., Busschbach, P., Martini, L., Morrow, M.,
Nadeau, T., and Y(J). Stein, "Pseudowire (PW) Operations, Nadeau, T., and Y(J). Stein, "Pseudowire (PW) Operations,
Administration, and Maintenance (OAM) Message Mapping", Administration, and Maintenance (OAM) Message Mapping",
RFC 6310, July 2011. RFC 6310, July 2011.
[RFC6371] Busi, I. and D. Allan, "Operations, Administration, and [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and
Maintenance Framework for MPLS-Based Transport Networks", Maintenance Framework for MPLS-Based Transport Networks",
RFC 6371, September 2011. RFC 6371, September 2011.
[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.
[RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas,
"Label Distribution Protocol Extensions for Point-to- "Label Distribution Protocol Extensions for Point-to-
Multipoint and Multipoint-to-Multipoint Label Switched Multipoint and Multipoint-to-Multipoint Label Switched
Paths", RFC 6388, November 2011. Paths", RFC 6388, November 2011.
[RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for
Performing Label Switched Path Ping (LSP Ping) over MPLS Performing Label Switched Path Ping (LSP Ping) over MPLS
Tunnels", RFC 6424, November 2011. Tunnels", RFC 6424, November 2011.
[RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa, [RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa,
S., and T. Nadeau, "Detecting Data-Plane Failures in S., and T. Nadeau, "Detecting Data-Plane Failures in
Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC
6425, November 2011. 6425, November 2011.
[RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS [RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS
On-Demand Connectivity Verification and Route Tracing", On-Demand Connectivity Verification and Route Tracing",
RFC 6426, November 2011. RFC 6426, 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.
[RFC6435] Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, M., [RFC6435] Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, M.,
and X. Dai, "MPLS Transport Profile Lock Instruct and and X. Dai, "MPLS Transport Profile Lock Instruct and
Loopback Functions", RFC 6435, November 2011. Loopback Functions", RFC 6435, November 2011.
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
for Equal Cost Multipath Routing and Link Aggregation in for Equal Cost Multipath Routing and Link Aggregation in
Tunnels", RFC 6438, November 2011. Tunnels", RFC 6438, November 2011.
[RFC6478] Martini, L., Swallow, G., Heron, G., and M. Bocci, [RFC6478] Martini, L., Swallow, G., Heron, G., and M. Bocci,
"Pseudowire Status for Static Pseudowires", RFC 6478, May "Pseudowire Status for Static Pseudowires", RFC 6478, May
skipping to change at page 51, line 14 skipping to change at page 53, line 34
[RFC6669] Sprecher, N. and L. Fang, "An Overview of the Operations, [RFC6669] Sprecher, N. and L. Fang, "An Overview of the Operations,
Administration, and Maintenance (OAM) Toolset for MPLS- Administration, and Maintenance (OAM) Toolset for MPLS-
Based Transport Networks", RFC 6669, July 2012. Based Transport Networks", RFC 6669, July 2012.
[RFC6670] Sprecher, N. and KY. Hong, "The Reasons for Selecting a [RFC6670] Sprecher, N. and KY. Hong, "The Reasons for Selecting a
Single Solution for MPLS Transport Profile (MPLS-TP) Single Solution for MPLS Transport Profile (MPLS-TP)
Operations, Administration, and Maintenance (OAM)", RFC Operations, Administration, and Maintenance (OAM)", RFC
6670, July 2012. 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 [RFC6829] Chen, M., Pan, P., Pignataro, C., and R. Asati, "Label
Switched Path (LSP) Ping for Pseudowire Forwarding Switched Path (LSP) Ping for Pseudowire Forwarding
Equivalence Classes (FECs) Advertised over IPv6", RFC Equivalence Classes (FECs) Advertised over IPv6", RFC
6829, January 2013. 6829, January 2013.
[RFC7023] Mohan, D., Bitar, N., Sajassi, A., DeLord, S., Niger, P., [RFC7023] Mohan, D., Bitar, N., Sajassi, A., DeLord, S., Niger, P.,
and R. Qiu, "MPLS and Ethernet Operations, Administration, and R. Qiu, "MPLS and Ethernet Operations, Administration,
and Maintenance (OAM) Interworking", RFC 7023, October and Maintenance (OAM) Interworking", RFC 7023, October
2013. 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.
Appendix A. Organization of References Section Appendix A. Organization of References Section
The References section is split into Normative and Informative The References section is split into Normative and Informative
subsections. References that directly specify forwarding subsections. References that directly specify forwarding
encapsulations or behaviors are listed as normative. References encapsulations or behaviors are listed as normative. References
which describe signaling only, though normative with respect to which describe signaling only, though normative with respect to
signaling, are listed as informative. They are informative with signaling, are listed as informative. They are informative with
respect to MPLS forwarding. respect to MPLS forwarding.
Authors' Addresses Authors' Addresses
skipping to change at page 52, line 4 skipping to change at page 54, line 25
Curtis Villamizar (editor) Curtis Villamizar (editor)
Outer Cape Cod Network Consulting, LLC Outer Cape Cod Network Consulting, LLC
Email: curtis@occnc.com Email: curtis@occnc.com
Kireeti Kompella Kireeti Kompella
Juniper Networks Juniper Networks
Email: kireeti@juniper.net Email: kireeti@juniper.net
Shane Amante Shane Amante
Apple Inc. Apple Inc.
1 Infinite Loop 1 Infinite Loop
Cupertino, California 95014 Cupertino, California 95014
Email: samante@apple.com Email: samante@apple.com
Andrew Malis Andrew Malis
Consultant Huawei Technologies
Email: agmalis@gmail.com Email: agmalis@gmail.com
Carlos Pignataro Carlos Pignataro
Cisco Systems Cisco Systems
7200-12 Kit Creek Road 7200-12 Kit Creek Road
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
US US
Email: cpignata@cisco.com Email: cpignata@cisco.com
 End of changes. 77 change blocks. 
177 lines changed or deleted 267 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/