< draft-ietf-mpls-forwarding-02.txt   draft-ietf-mpls-forwarding-03.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: April 14, 2014 Contrail Systems Expires: May 18, 2014 Juniper Networks
S. Amante S. Amante
Level 3 Communications, Inc. Apple Inc.
A. Malis A. Malis
Verizon Consultant
C. Pignataro C. Pignataro
Cisco Cisco
October 11, 2013 November 14, 2013
MPLS Forwarding Compliance and Performance Requirements MPLS Forwarding Compliance and Performance Requirements
draft-ietf-mpls-forwarding-02 draft-ietf-mpls-forwarding-03
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.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 April 14, 2014. This Internet-Draft will expire on May 18, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . 9 1.3. Apparent Misconceptions . . . . . . . . . . . . . . . . . 8
1.4. Target Audience . . . . . . . . . . . . . . . . . . . . . 10 1.4. Target Audience . . . . . . . . . . . . . . . . . . . . . 9
2. Forwarding Issues . . . . . . . . . . . . . . . . . . . . . . 11 2. Forwarding Issues . . . . . . . . . . . . . . . . . . . . . . 10
2.1. Forwarding Basics . . . . . . . . . . . . . . . . . . . . 11 2.1. Forwarding Basics . . . . . . . . . . . . . . . . . . . . 10
2.1.1. MPLS Special Purpose Labels . . . . . . . . . . . . . 12 2.1.1. MPLS Special Purpose Labels . . . . . . . . . . . . . 11
2.1.2. MPLS Differentiated Services . . . . . . . . . . . . . 13 2.1.2. MPLS Differentiated Services . . . . . . . . . . . . 12
2.1.3. Time Synchronization . . . . . . . . . . . . . . . . . 14 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) . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . 17
2.2. MPLS Multicast . . . . . . . . . . . . . . . . . . . . . . 18 2.2. MPLS Multicast . . . . . . . . . . . . . . . . . . . . . 17
2.3. Packet Rates . . . . . . . . . . . . . . . . . . . . . . . 19 2.3. Packet Rates . . . . . . . . . . . . . . . . . . . . . . 18
2.4. MPLS Multipath Techniques . . . . . . . . . . . . . . . . 21 2.4. MPLS Multipath Techniques . . . . . . . . . . . . . . . . 20
2.4.1. Pseudowire Control Word . . . . . . . . . . . . . . . 21 2.4.1. Pseudowire Control Word . . . . . . . . . . . . . . . 21
2.4.2. Large Microflows . . . . . . . . . . . . . . . . . . . 22 2.4.2. Large Microflows . . . . . . . . . . . . . . . . . . 22
2.4.3. Pseudowire Flow Label . . . . . . . . . . . . . . . . 22 2.4.3. Pseudowire Flow Label . . . . . . . . . . . . . . . . 22
2.4.4. MPLS Entropy Label . . . . . . . . . . . . . . . . . . 23 2.4.4. MPLS Entropy Label . . . . . . . . . . . . . . . . . 22
2.4.5. Fields Used for Multipath Load Balance . . . . . . . . 23 2.4.5. Fields Used for Multipath Load Balance . . . . . . . 23
2.4.5.1. MPLS Fields in Multipath . . . . . . . . . . . . . 23 2.4.5.1. MPLS Fields in Multipath . . . . . . . . . . . . 23
2.4.5.2. IP Fields in Multipath . . . . . . . . . . . . . . 25 2.4.5.2. IP Fields in Multipath . . . . . . . . . . . . . 25
2.4.5.3. Fields Used in Flow Label . . . . . . . . . . . . 27 2.4.5.3. Fields Used in Flow Label . . . . . . . . . . . . 26
2.4.5.4. Fields Used in Entropy Label . . . . . . . . . . . 27 2.4.5.4. Fields Used in Entropy Label . . . . . . . . . . 26
2.5. MPLS-TP and UHP . . . . . . . . . . . . . . . . . . . . . 27 2.5. MPLS-TP and UHP . . . . . . . . . . . . . . . . . . . . . 27
2.6. Local Delivery of Packets . . . . . . . . . . . . . . . . 28 2.6. Local Delivery of Packets . . . . . . . . . . . . . . . . 27
2.6.1. DoS Protection . . . . . . . . . . . . . . . . . . . . 28 2.6.1. DoS Protection . . . . . . . . . . . . . . . . . . . 28
2.6.2. MPLS OAM . . . . . . . . . . . . . . . . . . . . . . . 30 2.6.2. MPLS OAM . . . . . . . . . . . . . . . . . . . . . . 30
2.6.3. Pseudowire OAM . . . . . . . . . . . . . . . . . . . . 31 2.6.3. Pseudowire OAM . . . . . . . . . . . . . . . . . . . 31
2.6.4. MPLS-TP OAM . . . . . . . . . . . . . . . . . . . . . 31 2.6.4. MPLS-TP OAM . . . . . . . . . . . . . . . . . . . . . 31
2.6.5. MPLS OAM and Layer-2 OAM Interworking . . . . . . . . 33 2.6.5. MPLS OAM and Layer-2 OAM Interworking . . . . . . . . 32
2.6.6. Extent of OAM Support by Hardware . . . . . . . . . . 33 2.6.6. Extent of OAM Support by Hardware . . . . . . . . . . 33
2.7. Number and Size of Flows . . . . . . . . . . . . . . . . . 34 2.7. Number and Size of Flows . . . . . . . . . . . . . . . . 34
3. Questions for Suppliers . . . . . . . . . . . . . . . . . . . 35 3. Questions for Suppliers . . . . . . . . . . . . . . . . . . . 34
3.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . . 35 3.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . 34
3.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 36 3.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 36
3.3. Multipath Capabilities and Performance . . . . . . . . . . 37 3.3. Multipath Capabilities and Performance . . . . . . . . . 37
3.4. Pseudowire Capabilities and Performance . . . . . . . . . 38 3.4. Pseudowire Capabilities and Performance . . . . . . . . . 37
3.5. Entropy Label Support and Performance . . . . . . . . . . 38 3.5. Entropy Label Support and Performance . . . . . . . . . . 38
3.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . . 38 3.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . 38
3.7. OAM Capabilities and Performance . . . . . . . . . . . . . 39 3.7. OAM Capabilities and Performance . . . . . . . . . . . . 38
4. Forwarding Compliance and Performance Testing . . . . . . . . 39 4. Forwarding Compliance and Performance Testing . . . . . . . . 39
4.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . . 40 4.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . 39
4.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 40 4.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 40
4.3. Multipath Capabilities and Performance . . . . . . . . . . 41 4.3. Multipath Capabilities and Performance . . . . . . . . . 40
4.4. Pseudowire Capabilities and Performance . . . . . . . . . 42 4.4. Pseudowire Capabilities and Performance . . . . . . . . . 41
4.5. Entropy Label Support and Performance . . . . . . . . . . 42 4.5. Entropy Label Support and Performance . . . . . . . . . . 42
4.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . . 43 4.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . 42
4.7. OAM Capabilities and Performance . . . . . . . . . . . . . 43 4.7. OAM Capabilities and Performance . . . . . . . . . . . . 43
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
7. Security Considerations . . . . . . . . . . . . . . . . . . . 45 7. Security Considerations . . . . . . . . . . . . . . . . . . . 44
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
8.1. Normative References . . . . . . . . . . . . . . . . . . . 45 8.1. Normative References . . . . . . . . . . . . . . . . . . 45
8.2. Informative References . . . . . . . . . . . . . . . . . . 46 8.2. Informative References . . . . . . . . . . . . . . . . . 46
Appendix A. Organization of References Section . . . . . . . . . 51 Appendix A. Organization of References Section . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
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
skipping to change at page 7, line 25 skipping to change at page 7, line 4
OTN Optical Transport Network OTN Optical Transport Network
P Provider router (LDP) P Provider router (LDP)
P2MP Point to Multi-Point P2MP Point to Multi-Point
PE Provider Edge router (LDP) PE Provider Edge router (LDP)
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 (MPLS-TP linear protection)
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 41 skipping to change at page 9, line 17
label stack depth, except where multiple pop operations are label stack depth, except where multiple pop operations are
required. See Section 2.1. required. See Section 2.1.
4. Research has shown that long bursts of short packets with 40 byte 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. or 44 byte IP payload sizes in these bursts are quite common.
This is due to TCP ACK compression [ACK-compression]. The This is due to TCP ACK compression [ACK-compression]. The
following two sub-bullets constitutes advice that reflects very following two sub-bullets constitutes advice that reflects very
common hard requirements of providers. Implementers may ignore common hard requirements of providers. Implementers may ignore
this advice but should consider the risk of doing so. this advice but should consider the risk of doing so.
A. A forwarding engine SHOULD, if practical, be able to sustain a. A forwarding engine SHOULD, if practical, be able to sustain
an arbitrarily long sequence of small packets arriving at an arbitrarily long sequence of small packets arriving at
full interface rate. full interface rate.
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 implementer and system designer 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
skipping to change at page 10, line 27 skipping to change at page 10, line 4
6. The implementer and system designer SHOULD support adding a 6. 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 7. 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
forwarding chip. (audience: implementer) forwarding chip. (audience: implementer)
3. Provide a checklist of features and performance specifications to 3. Provide a checklist of features and performance specifications to
request. (audience: systems designer, deployer) request. (audience: systems designer, deployer)
4. Provide a set of tests to perform. (audience: systems designer, 4. Provide a set of tests to perform. (audience: systems designer,
deployer). deployer).
The implementer, systems designer, and deployer have a transitive The implementer, systems designer, and deployer have a transitive
supplier customer relationship. It is in the best interest of the supplier customer relationship. It is in the best interest of the
supplier to review their product against their customer's checklist supplier to review their product against their customer's checklist
and customer's customer's checklist if applicable. and customer's customer's checklist if applicable.
2. Forwarding Issues 2. Forwarding Issues
A brief review of forwarding issues is provided in the subsections A brief review of forwarding issues is provided in the subsections
skipping to change at page 12, line 31 skipping to change at page 12, line 7
general purpose CPU or other highly programmable hardware. For general purpose CPU or other highly programmable hardware. For
example, ELI will only be sent to LSR which have signaled support for example, ELI will only be sent to LSR which have signaled support for
[RFC6790] and high OAM packet rate must be negotiated among [RFC6790] and high OAM packet rate must be negotiated among
endpoints. 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, 16- values 256-1048575 are used. If only the standards action range,
239, and the experimental range, 240-255, are used, then a table of 16-239, and the experimental range, 240-255, are used, then a table
256 entries can be used. of 256 entries can be used.
Unknown special purpose labels and unknown extended special purpose Unknown special purpose labels and unknown extended special purpose
labels are handled the same. When an unknown special purpose label labels are handled the same. When an unknown special purpose label
is encountered or a special purpose label not directly handled in is encountered or a special purpose label not directly handled in
forwarding hardware is encountered, the packet should be sent to a forwarding hardware is encountered, the packet should be sent to a
general purpose CPU by default. If this capability is supported, general purpose CPU by default. If this capability is supported,
there must be an option to either drop or rate limit such packets on there must be an option to either drop or rate limit such packets on
a per special purpose label value basis. a per special purpose label value basis.
2.1.2. MPLS Differentiated Services 2.1.2. MPLS Differentiated Services
skipping to change at page 14, line 33 skipping to change at page 14, line 11
Accurate time synchronization in addition to being generally useful Accurate time synchronization in addition to being generally useful
is required for MPLS-TP delay measurement (DM) OAM. See is required for MPLS-TP delay measurement (DM) OAM. See
Section 2.6.4. Section 2.6.4.
2.1.4. Uses of Multiple Label Stack Entries 2.1.4. Uses of Multiple Label Stack Entries
MPLS deployments in the early part of the prior decade (circa 2000) 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 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 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 of the network, without adding deployment complexity. RSVP-TE was
favored, generally in the network core, where traffic engineering favored, generally in the network core, where traffic engineering and
and/or fast reroute were considered important. /or fast reroute were considered important.
Both LDP and RSVP-TE are used simultaneously within major Service Both LDP and RSVP-TE are used simultaneously within major Service
Provider networks using a technique known as "LDP over RSVP-TE Provider networks using a technique known as "LDP over RSVP-TE
Tunneling". This technique allows service providers to carry LDP Tunneling". This technique allows service providers to carry LDP
tunnels inside RSVP-TE tunnels. This makes it possible to take tunnels inside RSVP-TE tunnels. This makes it possible to take
advantage of the Traffic Engineering and Fast Re-Route on more advantage of the Traffic Engineering and Fast Re-Route on more
expensive Inter-City and Inter-Continental transport paths. The expensive Inter-City and Inter-Continental transport paths. The
ingress RSVP-TE PEs places many LDP tunnels on a single RSVP-TE LSP ingress RSVP-TE PEs places many LDP tunnels on a single RSVP-TE LSP
and carries it to the egress RSVP-TE PE. The LDP PEs are situated 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 further from the core, for example within a metro network. LDP over
skipping to change at page 20, line 46 skipping to change at page 20, line 35
respectively, and this delay only applies if a 4K burst of short respectively, and this delay only applies if a 4K burst of short
packets occurs. When no burst of short packets was being processed, packets occurs. When no burst of short packets was being processed,
no delay is added. no delay is added.
Packet rate requirements apply regardless of which network tier Packet rate requirements apply regardless of which network tier
equipment is deployed in. Whether deployed in the network core or equipment is deployed in. Whether deployed in the network core or
near the network edges, one of the two conditions MUST be met if near the network edges, one of the two conditions MUST be met if
Differentiated Services requirements are to be met: Differentiated Services requirements are to be met:
1. Packets must be processed at full line rate with minimum sized 1. Packets must be processed at full line rate with minimum sized
packets. -OR- packets. -OR-
2. Packets must be processed at a rate well under generally accepted 2. Packets must be processed at a rate well under generally accepted
average packet sizes, with sufficient buffering prior to the average packet sizes, with sufficient buffering prior to the
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
skipping to change at page 25, line 6 skipping to change at page 24, line 43
multipath load balancing as it violates Differentiated Services multipath load balancing as it violates Differentiated Services
Ordered Aggregate (OA) requirements in these two instances. Ordered Aggregate (OA) requirements in these two instances.
Use of the MPLS label entry S bit would result in putting OAM traffic 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 on a different path if the addition of a GAL at the bottom of stack
removed the S bit from the prior label. removed the S bit from the prior label.
If an ELI label is found, then if the LSR supports entropy label, the If an ELI label is found, then if the LSR supports entropy label, the
EL label field in the next label entry (the EL) SHOULD be used and EL label field in the next label entry (the EL) SHOULD be used and
the search for additional entropy within the packet SHOULD be the search for additional entropy within the packet SHOULD be
terminated. Failure to terminate the search will impact client terminated. Failure to terminate the search will impact client MPLS-
MPLS-TP LSP carried within server MPLS LSP. A network operator has TP LSP carried within server MPLS LSP. A network operator has the
the option to use administrative attributes as a means to identify option to use administrative attributes as a means to identify LSR
LSR which do not terminate the entropy search at the first EL. which do not terminate the entropy search at the first EL.
Administrative attributes are defined in [RFC3209]. Some Administrative attributes are defined in [RFC3209]. Some
configuration is required to support this. configuration is required to support this.
If the label removed by a PHP pop is not used, then for any PW for 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 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 some networks it is infeasible to put all PW traffic on one component
link. Any PW which does not use CW will be improperly split link. Any PW which does not use CW will be improperly split
regardless of whether the label removed by a PHP pop is used. regardless of whether the label removed by a PHP pop is used.
Therefore the PHP pop label SHOULD be used as recommended above. Therefore the PHP pop label SHOULD be used as recommended above.
skipping to change at page 26, line 23 skipping to change at page 26, line 13
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, UDP-lite, SCTP and DCCP SHOULD be provided,
particularly for edge or access equipment where additional particularly for edge or access equipment where additional
entropy may be needed. Equipment SHOULD also use RTP, UDP-lite, entropy may be needed. Equipment SHOULD also use RTP, UDP-lite,
SCTP and DCCP headers when creating an entropy label. 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. The use of tunneling header information is out
of scope for this document. of scope for this document.
This document makes the following recommendations. These This document makes the following recommendations. These
skipping to change at page 35, line 17 skipping to change at page 34, line 47
The following questions should be asked of a supplier. These The following questions should be asked of a supplier. These
questions are grouped into broad categories. The questions questions are grouped into broad categories. The questions
themselves are intended to be an open ended question to the supplier. themselves are intended to be an open ended question to the supplier.
The tests in Section 4 are intended to verify whether the supplier The tests in Section 4 are intended to verify whether the supplier
disclosed any compliance or performance limitations completely and disclosed any compliance or performance limitations completely and
accurately. accurately.
3.1. Basic Compliance 3.1. Basic Compliance
Q#1 Can the implementation forward packets with an arbitrarily Q#1 Can the implementation forward packets with an arbitrarily
large stack depth? What limitations exist, and under what large stack depth? What limitations exist, and under what
circumstances do further limitations come into play (such as circumstances do further limitations come into play (such as high
high packet rate or specific features enabled or specific types packet rate or specific features enabled or specific types of
of packet processing)? See Section 2.1. packet processing)? See Section 2.1.
Q#2 Is the entire set of basic MPLS functionality described in Q#2 Is the entire set of basic MPLS functionality described in
Section 2.1 supported? Section 2.1 supported?
Q#3 Are the set of MPLS special purpose labels handled correctly Q#3 Are the set of MPLS special purpose labels handled correctly
and with adequate performance? Are extended special purpose and with adequate performance? Are extended special purpose
labels handled correctly and with adequate performance? See labels handled correctly and with adequate performance? See
Section 2.1.1. Section 2.1.1.
Q#4 Are mappings of label value and TC to PHB handled correctly, Q#4 Are mappings of label value and TC to PHB handled correctly,
including RFC3270 L-LSP mappings and RFC4124 CT mappings to including RFC3270 L-LSP mappings and RFC4124 CT mappings to PHB?
PHB? See Section 2.1.2. See Section 2.1.2.
Q#5 Is time synchronization adequately supported in forwarding Q#5 Is time synchronization adequately supported in forwarding
hardware? hardware?
A. Are both PTP and NTP formats supported? a. Are both PTP and NTP formats supported?
B. Is the accuracy of timestamp insertion and incoming b. Is the accuracy of timestamp insertion and incoming stamping
stamping sufficient? sufficient?
See Section 2.1.3. See Section 2.1.3.
Q#6 Is link bundling supported? Q#6 Is link bundling supported?
A. Can LSP be pinned to specific components? a. Can LSP be pinned to specific components?
B. Is the "all-ones" component link supported? b. Is the "all-ones" component link supported?
See Section 2.1.5. See Section 2.1.5.
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? b. Are the pipe, short-pipe, and uniform models supported? Are
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
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
are congested?
A. Are packets dropped on uncongested outputs if some outputs b. Is performance limited in high fanout situations?
are congested?
B. Is performance limited in high fanout situations?
See Section 2.2. See Section 2.2.
3.2. Basic Performance 3.2. Basic Performance
Q#11 Can very small packets be forwarded at full line rate on all Q#11 Can very small packets be forwarded at full line rate on all
interfaces indefinitely? What limitations exist, and under interfaces indefinitely? What limitations exist, and under what
what circumstances do further limitations come into play (such circumstances do further limitations come into play (such as
as specific features enabled or specific types of packet specific features enabled or specific types of packet
processing)? processing)?
Q#12 Customers must decide whether to relax the prior requirement Q#12 Customers must decide whether to relax the prior requirement and
and to what extent. If the answer to the prior question to what extent. If the answer to the prior question indicates
indicates that limitations exist, then: that limitations exist, then:
A. What is the smallest packet size where full line rate a. What is the smallest packet size where full line rate
forwarding can be supported? forwarding can be supported?
B. What is the longest burst of full rate small packets that b. What is the longest burst of full rate small packets that can
can be supported? be supported?
Specify circumstances (such as specific features enabled or Specify circumstances (such as specific features enabled or
specific types of packet processing) often impact these rates specific types of packet processing) often impact these rates and
and burst sizes. burst sizes.
Q#13 How many pop operations can be supported along with a swap Q#13 How many pop operations can be supported along with a swap
operation at full line rate while maintaining per LSP packet operation at full line rate while maintaining per LSP packet and
and byte counts for each pop and swap? This requirement is byte counts for each pop and swap? This requirement is
particularly relevant for MPLS-TP. particularly relevant for MPLS-TP.
Q#14 How many label push operations can be supported. While this Q#14 How many label push operations can be supported. While this
limitation is rarely an issue, it applies to both PHP and UHP, limitation is rarely an issue, it applies to both PHP and UHP,
unlike the pop limit which applies to UHP. unlike the pop limit which applies to UHP.
Q#15 For a worst case where all packets arrive on one LSP, what is Q#15 For a worst case where all packets arrive on one LSP, what is
the counter overflow time? Are any means provided to avoid the counter overflow time? Are any means provided to avoid
polling all counters at short intervals? This applies to both polling all counters at short intervals? This applies to both
MPLS and MPLS-TP. MPLS and MPLS-TP.
3.3. Multipath Capabilities and Performance 3.3. Multipath Capabilities and Performance
Multipath capabilities and performance do not apply to MPLS-TP but Multipath capabilities and performance do not apply to MPLS-TP but
apply to MPLS and apply if MPLS-TP is carried in MPLS. apply to MPLS and apply if MPLS-TP is carried in MPLS.
Q#16 How are large microflows accommodated? Is there active Q#16 How are large microflows accommodated? Is there active
management of the hash space mapping to output ports? See management of the hash space mapping to output ports? See
Section 2.4.2. Section 2.4.2.
Q#17 How many MPLS labels can be included in a hash based on the Q#17 How many MPLS labels can be included in a hash based on the MPLS
MPLS label stack? label stack?
Q#18 Is packet rate performance decreased beyond some number of Q#18 Is packet rate performance decreased beyond some number of
labels? labels?
Q#19 Can the IP header and payload information below the MPLS stack Q#19 Can the IP header and payload information below the MPLS stack
be used in the hash? If so, which IP fields, payload types and be used in the hash? If so, which IP fields, payload types and
payload fields are supported? payload fields are supported?
Q#20 At what maximum MPLS label stack depth can Bottom of Stack and Q#20 At what maximum MPLS label stack depth can Bottom of Stack and
an IP header appear without impacting packet rate performance? an IP header appear without impacting packet rate performance?
Q#21 Are special purpose labels excluded from the label stack hash? Q#21 Are special purpose labels excluded from the label stack hash?
Are extended purpose labels excluded from the label stack hash? Are extended purpose labels excluded from the label stack hash?
See Section 2.4.5.1. See Section 2.4.5.1.
Q#22 How is multipath performance affected by very large flows or an Q#22 How is multipath performance affected by very large flows or an
extremely large number of flows, or by very short lived flows? extremely large number of flows, or by very short lived flows?
See Section 2.7. See Section 2.7.
3.4. Pseudowire Capabilities and Performance 3.4. Pseudowire Capabilities and Performance
Q#23 Is the pseudowire control word supported? Q#23 Is the pseudowire control word supported?
Q#24 What is the maximum rate of pseudowire encapsulation and Q#24 What is the maximum rate of pseudowire encapsulation and
decapsulation? Apply the same questions as in Base Performance decapsulation? Apply the same questions as in Base Performance
for any packet based pseudowire such as IP VPN or Ethernet. for any packet based pseudowire such as IP VPN or Ethernet.
Q#25 Does inclusion of a pseudowire control word impact performance? Q#25 Does inclusion of a pseudowire control word impact performance?
Q#26 Are flow labels supported? Q#26 Are flow labels supported?
Q#27 If so, what fields are hashed on for the flow label for Q#27 If so, what fields are hashed on for the flow label for
different types of pseudowires? different types of pseudowires?
Q#28 Does inclusion of a flow label impact performance? Q#28 Does inclusion of a flow label impact performance?
3.5. Entropy Label Support and Performance 3.5. Entropy Label Support and Performance
Q#29 Can an entropy label be added when acting as in ingress LER and Q#29 Can an entropy label be added when acting as in ingress LER and
can it be removed when acting as an egress LER? can it be removed when acting as an egress LER?
Q#30 If so, what fields are hashed on for the entropy label? Q#30 If so, what fields are hashed on for the entropy label?
Q#31 Does adding or removing an entropy label impact packet rate Q#31 Does adding or removing an entropy label impact packet rate
performance? performance?
Q#32 Can an entropy label be detected in the label stack, used in Q#32 Can an entropy label be detected in the label stack, used in the
the hash, and properly terminate the search for further hash, and properly terminate the search for further information
information to hash on? to hash on?
Q#33 Does using an entropy label have any negative impact on Q#33 Does using an entropy label have any negative impact on
performance? It should have no impact or a positive impact. performance? It should have no impact or a positive impact.
3.6. DoS Protection 3.6. DoS Protection
Q#34 For each control and management plane protocol in use, what Q#34 For each control and management plane protocol in use, what
measures are taken to provide DoS attack hardening? measures are taken to provide DoS attack hardening?
Q#35 Have DoS attack tests been performed? Q#35 Have DoS attack tests been performed?
Q#36 Can compromise of an internal computer on a management subnet Q#36 Can compromise of an internal computer on a management subnet be
be leveraged for any form of attack including DoS attack? leveraged for any form of attack including DoS attack?
3.7. OAM Capabilities and Performance 3.7. OAM Capabilities and Performance
Q#37 What OAM proactive and on-demand mechanisms are supported? Q#37 What OAM proactive and on-demand mechanisms are supported?
Q#38 What performance limits exist under high proactive monitoring Q#38 What performance limits exist under high proactive monitoring
rates? rates?
Q#39 Can excessively high proactive monitoring rates impact control Q#39 Can excessively high proactive monitoring rates impact control
plane performance or cause control plane instability? plane performance or cause control plane instability?
Q#40 Ask the prior questions for each of the following. Q#40 Ask the prior questions for each of the following.
A. MPLS OAM a. MPLS OAM
B. Pseudowire OAM b. Pseudowire OAM
C. MPLS-TP OAM c. MPLS-TP OAM
D. Layer-2 OAM Interworking d. Layer-2 OAM Interworking
See Section 2.6.2. See Section 2.6.2.
4. Forwarding Compliance and Performance Testing 4. Forwarding Compliance and Performance Testing
Packet rate performance of equipment supporting a large number of 10 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 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 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 traffic was barely viable 20 years ago, but is no longer at all
viable. Though custom microcode has been used on specialized router viable. Though custom microcode has been used on specialized router
forwarding cards to serve the purpose of generating test traffic and forwarding cards to serve the purpose of generating test traffic and
measuring it, for the most part performance testing will require measuring it, for the most part performance testing will require
skipping to change at page 40, line 17 skipping to change at page 39, line 43
The tests in Section 4.1 should be repeated under various conditions The tests in Section 4.1 should be repeated under various conditions
to retest basic performance when critical capabilities are enabled. to retest basic performance when critical capabilities are enabled.
Complete repetition of the performance tests enabling each capability Complete repetition of the performance tests enabling each capability
and combinations of capabilities would be very time intensive, and combinations of capabilities would be very time intensive,
therefore a reduced set of performance tests can be used to gauge the therefore a reduced set of performance tests can be used to gauge the
impact of enabling specific capabilities. impact of enabling specific capabilities.
4.1. Basic Compliance 4.1. Basic Compliance
T#1 Test forwarding at a high rate for packets with varying number T#1 Test forwarding at a high rate for packets with varying number
of label entries. While packets with more than a dozen label of label entries. While packets with more than a dozen label
entries are unlikely to be used in any practical scenario today, entries are unlikely to be used in any practical scenario today,
it is useful to know if limitations exists. it is useful to know if limitations exists.
T#2 For each of the questions listed under "Basic Compliance" in T#2 For each of the questions listed under "Basic Compliance" in
Section 3, verify the claimed compliance. For any functionality Section 3, verify the claimed compliance. For any functionality
considered critical to a deployment, where applicable considered critical to a deployment, where applicable performance
performance using each capability under load should be verified using each capability under load should be verified in addition
in addition to basic compliance. to basic compliance.
4.2. Basic Performance 4.2. Basic Performance
T#3 Test packet forwarding at full line rate with small packets. T#3 Test packet forwarding at full line rate with small packets.
See [RFC5695]. The most likely case to fail is the smallest See [RFC5695]. The most likely case to fail is the smallest
packet size. Also test with packet sizes in four byte packet size. Also test with packet sizes in four byte increments
increments ranging from payload sizes or 40 to 128 bytes. ranging from payload sizes or 40 to 128 bytes.
T#4 If the prior tests did not succeed for all packet sizes, then T#4 If the prior tests did not succeed for all packet sizes, then
perform the following tests. perform the following tests.
A. Increase the packet size by 4 bytes until a size is found a. Increase the packet size by 4 bytes until a size is found
that can be forwarded at full rate. that can be forwarded at full rate.
B. Inject bursts of consecutive small packets into a stream of b. Inject bursts of consecutive small packets into a stream of
larger packets. Allow some time for recovery between larger packets. Allow some time for recovery between bursts.
bursts. Increase the number of packets in the burst until Increase the number of packets in the burst until packets are
packets are dropped. dropped.
T#5 Send test traffic where a swap operation is required. Also set T#5 Send test traffic where a swap operation is required. Also set
up multiple LSP carried over other LSP where the device under up multiple LSP carried over other LSP where the device under
test (DUT) is the egress of these LSP. Create test packets such test (DUT) is the egress of these LSP. Create test packets such
that the swap operation is performed after pop operations, that the swap operation is performed after pop operations,
increasing the number of pop operations until forwarding of increasing the number of pop operations until forwarding of small
small packets at full line rate can no longer be supported. packets at full line rate can no longer be supported. Also check
Also check to see how many pop operations can be supported to see how many pop operations can be supported before the full
before the full set of counters can no longer be maintained. set of counters can no longer be maintained. This requirement is
This requirement is particularly relevant for MPLS-TP. particularly relevant for MPLS-TP.
T#6 Send all traffic on one LSP and see if the counters become T#6 Send all traffic on one LSP and see if the counters become
inaccurate. Often counters on silicon are much smaller than the inaccurate. Often counters on silicon are much smaller than the
64 bit packet and byte counters in IETF MIB. System developers 64 bit packet and byte counters in IETF MIB. System developers
should consider what counter polling rate is necessary to should consider what counter polling rate is necessary to
maintain accurate counters and whether those polling rates are maintain accurate counters and whether those polling rates are
practical. Relevant MIBs for MPLS are discussed in [RFC4221] practical. Relevant MIBs for MPLS are discussed in [RFC4221] and
and [RFC6639]. [RFC6639].
4.3. Multipath Capabilities and Performance 4.3. Multipath Capabilities and Performance
Multipath capabilities do not apply to MPLS-TP but apply to MPLS and Multipath capabilities do not apply to MPLS-TP but apply to MPLS and
apply if MPLS-TP is carried in MPLS. apply if MPLS-TP is carried in MPLS.
T#7 Send traffic at a rate well exceeding the capacity of a single T#7 Send traffic at a rate well exceeding the capacity of a single
multipath component link, and where entropy exists only below multipath component link, and where entropy exists only below the
the top of stack. If only the top label is used this test will top of stack. If only the top label is used this test will fail
fail immediately. immediately.
T#8 Move the labels with entropy down in the stack until either the T#8 Move the labels with entropy down in the stack until either the
full forwarding rate can no longer be supported or most or all full forwarding rate can no longer be supported or most or all
packets try to use the same component link. packets try to use the same component link.
T#9 Repeat the two tests above with the entropy contained in IP T#9 Repeat the two tests above with the entropy contained in IP
headers or IP payload fields below the label stack rather than headers or IP payload fields below the label stack rather than in
in the label stack. Test with the set of IP headers or IP the label stack. Test with the set of IP headers or IP payload
payload fields considered relevant to the deployment or to the fields considered relevant to the deployment or to the target
target market. market.
T#10 Determine whether traffic that contains a pseudowire control T#10 Determine whether traffic that contains a pseudowire control
word is interpreted as IP traffic. Information in the payload word is interpreted as IP traffic. Information in the payload
MUST NOT be used in the load balancing if the first nibble of MUST NOT be used in the load balancing if the first nibble of the
the packet is not 4 or 6 (IPv4 or IPv6). packet is not 4 or 6 (IPv4 or IPv6).
T#11 Determine whether special purpose labels and extended special T#11 Determine whether special purpose labels and extended special
purpose labels are excluded from the label stack hash. They purpose labels are excluded from the label stack hash. They MUST
MUST be excluded. be excluded.
T#12 Perform testing in the presence of combinations of: T#12 Perform testing in the presence of combinations of:
A. Very large microflows. a. Very large microflows.
B. Relatively short lived high capacity flows. b. Relatively short lived high capacity flows.
C. Extremely large numbers of flows. c. Extremely large numbers of flows.
D. Very short lived small flows. d. Very short lived small flows.
4.4. Pseudowire Capabilities and Performance 4.4. Pseudowire Capabilities and Performance
T#13 Ensure that pseudowire can be set up with a pseudowire label T#13 Ensure that pseudowire can be set up with a pseudowire label and
and pseudowire control word added at ingress and the pseudowire pseudowire control word added at ingress and the pseudowire label
label and pseudowire control word removed at egress. and pseudowire control word removed at egress.
T#14 For pseudowire that contains variable length payload packets, T#14 For pseudowire that contains variable length payload packets,
repeat performance tests listed under "Basic Performance" for repeat performance tests listed under "Basic Performance" for
pseudowire ingress and egress functions. pseudowire ingress and egress functions.
T#15 Repeat pseudowire performance tests with and without a T#15 Repeat pseudowire performance tests with and without a
pseudowire control word. pseudowire control word.
T#16 Determine whether pseudowire can be set up with a pseudowire T#16 Determine whether pseudowire can be set up with a pseudowire
label, flow label, and pseudowire control word added at ingress label, flow label, and pseudowire control word added at ingress
and the pseudowire label, flow label, and pseudowire control and the pseudowire label, flow label, and pseudowire control word
word removed at egress. removed at egress.
T#17 Determine which payload fields are used to create the flow T#17 Determine which payload fields are used to create the flow label
label and whether the set of fields and algorithm provide and whether the set of fields and algorithm provide sufficient
sufficient entropy for load balancing. entropy for load balancing.
T#18 Repeat pseudowire performance tests with flow labels included. T#18 Repeat pseudowire performance tests with flow labels included.
4.5. Entropy Label Support and Performance 4.5. Entropy Label Support and Performance
T#19 Determine whether entropy labels can be added at ingress and T#19 Determine whether entropy labels can be added at ingress and
removed at egress. removed at egress.
T#20 Determine which fields are used to create an entropy label. T#20 Determine which fields are used to create an entropy label.
Labels further down in the stack, including entropy labels Labels further down in the stack, including entropy labels
further down and IP headers or IP payload fields where further down and IP headers or IP payload fields where applicable
applicable should be used. Determine whether the set of fields should be used. Determine whether the set of fields and
and algorithm provide sufficient entropy for load balancing. algorithm provide sufficient entropy for load balancing.
T#21 Repeat performance tests under "Basic Performance" when entropy T#21 Repeat performance tests under "Basic Performance" when entropy
labels are used, where ingress or egress is the device under labels are used, where ingress or egress is the device under test
test (DUT). (DUT).
T#22 Determine whether an ELI is detected when acting as a midpoint T#22 Determine whether an ELI is detected when acting as a midpoint
LSR and whether the search for further information on which to LSR and whether the search for further information on which to
base the load balancing is used. Information below the entropy base the load balancing is used. Information below the entropy
label SHOULD NOT be used. label SHOULD NOT be used.
T#23 Ensure that the entropy label indicator and entropy label (ELI T#23 Ensure that the entropy label indicator and entropy label (ELI
and EL) are removed from the label stack during UHP and PHP and EL) are removed from the label stack during UHP and PHP
operations. operations.
T#24 Insure that operations on the TC field when adding and removing T#24 Insure that operations on the TC field when adding and removing
entropy label are correctly carried out. If TC is changed entropy label are correctly carried out. If TC is changed during
during a swap operation, the ability to transfer that change a swap operation, the ability to transfer that change MUST be
MUST be provided. The ability to suppress the transfer of TC provided. The ability to suppress the transfer of TC MUST also
MUST also be provided. See "pipe", "short pipe", and "uniform" be provided. See "pipe", "short pipe", and "uniform" models in
models in [RFC3443]. [RFC3443].
T#25 Repeat performance tests for midpoint LSR with entropy labels T#25 Repeat performance tests for midpoint LSR with entropy labels
found at various label stack depths. found at various label stack depths.
4.6. DoS Protection 4.6. DoS Protection
T#26 Actively attack LSR under high protocol churn load and T#26 Actively attack LSR under high protocol churn load and determine
determine control plane performance impact or successful DoS control plane performance impact or successful DoS under test
under test conditions. Specifically test for the following. conditions. Specifically test for the following.
A. TCP SYN attack against control plane and management plane a. TCP SYN attack against control plane and management plane
protocols using TCP, including CLI access (typically SSH protocols using TCP, including CLI access (typically SSH
protected login), NETCONF, etc. protected login), NETCONF, etc.
B. High traffic volume attack against control plane and b. High traffic volume attack against control plane and
management plane protocols not using TCP. management plane protocols not using TCP.
C. Attacks which can be performed from a compromised c. Attacks which can be performed from a compromised management
management subnet computer, but not one with authentication subnet computer, but not one with authentication keys.
keys.
D. Attacks which can be performed from a compromised peer d. Attacks which can be performed from a compromised peer within
within the control plane (internal domain and external the control plane (internal domain and external domain).
domain). Assume that per peering keys and per router ID Assume that per peering keys and per router ID keys rather
keys rather than network wide keys are in use. than network wide keys are in use.
See Section 2.6.1. See Section 2.6.1.
4.7. OAM Capabilities and Performance 4.7. OAM Capabilities and Performance
T#27 Determine maximum sustainable rates of BFD traffic. If BFD T#27 Determine maximum sustainable rates of BFD traffic. If BFD
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#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 PSC functionality, protection speed,
and AIS/RDI notification speed when a large number of and AIS/RDI notification speed when a large number of Management
Management Entities (ME) must be notified with AIS/RDI. 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 45, line 23 skipping to change at page 45, line 4
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
[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.
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
Protocol Label Switching (MPLS) Support of Differentiated Protocol Label Switching (MPLS) Support of Differentiated
Services", RFC 3270, May 2002. Services", RFC 3270, May 2002.
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing
in Multi-Protocol Label Switching (MPLS) Networks", in Multi-Protocol Label Switching (MPLS) Networks", RFC
RFC 3443, January 2003. 3443, January 2003.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May
May 2005. 2005.
[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.
[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.
[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.
[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, over an MPLS Packet Switched Network", RFC 6391, November
November 2011. 2011.
[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.
[ATM-EPD-and-PPD] [ATM-EPD-and-PPD]
"Dynamics of TCP Traffic over ATM Networks", IEEE Journal , "Dynamics of TCP Traffic over ATM Networks", IEEE
of Special Areas of Communication Vol 13 No 4, May 1995, Journal of Special Areas of Communication Vol 13 No 4, May
pp. 633-641., May 1995. 1995, pp. 633-641., May 1995.
[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", and Retiring Special Purpose MPLS Labels", draft-ietf-
draft-ietf-mpls-special-purpose-labels-03 (work in mpls-special-purpose-labels-03 (work in progress), July
progress), July 2013. 2013.
[I-D.ietf-pwe3-vccv-impl-survey-results] [I-D.ietf-pwe3-vccv-impl-survey-results]
Malis, A., "The Pseudowire (PW) & Virtual Circuit Malis, A., "The Pseudowire (PW) & Virtual Circuit
Connectivity Verification (VCCV) Implementation Survey Connectivity Verification (VCCV) Implementation Survey
Results", draft-ietf-pwe3-vccv-impl-survey-results-03 Results", draft-ietf-pwe3-vccv-impl-survey-results-03
(work in progress), October 2013. (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, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
September 1981. 1981.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474, December
December 1998. 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998. Services", RFC 2475, December 1998.
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999. "Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001. Label Switching Architecture", RFC 3031, January 2001.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP", RFC
RFC 3168, September 2001. 3168, September 2001.
[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.
[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.
[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, Diffserv-aware MPLS Traffic Engineering", RFC 4124, June
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.
[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", for Multi-Protocol Label Switched (MPLS) Networks", RFC
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.
[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, Cost Multipath Treatment in MPLS Networks", BCP 128, RFC
RFC 4928, June 2007. 4928, June 2007.
[RFC4950] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP [RFC4950] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP
Extensions for Multiprotocol Label Switching", RFC 4950, Extensions for Multiprotocol Label Switching", RFC 4950,
August 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. [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C.
Pignataro, "The Generalized TTL Security Mechanism Pignataro, "The Generalized TTL Security Mechanism
skipping to change at page 49, line 11 skipping to change at page 48, line 44
Transport Profile", RFC 5317, February 2009. Transport Profile", RFC 5317, February 2009.
[RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS
Multicast Encapsulations", RFC 5332, August 2008. 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.
[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, Benchmarking Methodology for IP Flows", RFC 5695, November
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 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, June 2010. (BFD)", RFC 5880, June 2010.
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"Bidirectional Forwarding Detection (BFD) for MPLS Label "Bidirectional Forwarding Detection (BFD) for MPLS Label
skipping to change at page 50, line 16 skipping to change at page 49, line 48
"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", Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC
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., [RFC6427] Swallow, G., Fulignoli, A., Vigoureux, M., Boutros, S.,
and D. Ward, "MPLS Fault Management Operations, and D. Ward, "MPLS Fault Management Operations,
Administration, and Maintenance (OAM)", RFC 6427, Administration, and Maintenance (OAM)", RFC 6427, November
November 2011. 2011.
[RFC6428] Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive [RFC6428] Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive
Connectivity Verification, Continuity Check, and Remote Connectivity Verification, Continuity Check, and Remote
Defect Indication for the MPLS Transport Profile", Defect Indication for the MPLS Transport Profile", RFC
RFC 6428, November 2011. 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, "Pseudowire Status for Static Pseudowires", RFC 6478, May
May 2012. 2012.
[RFC6639] King, D. and M. Venkatesan, "Multiprotocol Label Switching [RFC6639] King, D. and M. Venkatesan, "Multiprotocol Label Switching
Transport Profile (MPLS-TP) MIB-Based Management Transport Profile (MPLS-TP) MIB-Based Management
Overview", RFC 6639, June 2012. Overview", RFC 6639, June 2012.
[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)", Operations, Administration, and Maintenance (OAM)", RFC
RFC 6670, July 2012. 6670, July 2012.
[RFC6720] Pignataro, C. and R. Asati, "The Generalized TTL Security [RFC6720] Pignataro, C. and R. Asati, "The Generalized TTL Security
Mechanism (GTSM) for the Label Distribution Protocol Mechanism (GTSM) for the Label Distribution Protocol
(LDP)", RFC 6720, August 2012. (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", Equivalence Classes (FECs) Advertised over IPv6", RFC
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, and Maintenance (OAM) Interworking", RFC 7023, October
October 2013. 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
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
Contrail Systems Juniper Networks
Email: kireeti@juniper.net
Email: kireeti.kompella@gmail.com
Shane Amante Shane Amante
Level 3 Communications, Inc. Apple Inc.
1025 Eldorado Blvd 1 Infinite Loop
Broomfield, CO 80021 Cupertino, California 95014
Email: shane@level3.net Email: samante@apple.com
Andrew Malis Andrew Malis
Verizon Consultant
60 Sylvan Road
Waltham, MA 02451
Phone: +1 781-466-2362
Email: andrew.g.malis@verizon.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. 152 change blocks. 
380 lines changed or deleted 372 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/