draft-ietf-mpls-forwarding-08.txt   draft-ietf-mpls-forwarding-09.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: August 16, 2014 Juniper Networks Expires: September 5, 2014 Juniper Networks
S. Amante S. Amante
Apple Inc. Apple Inc.
A. Malis A. Malis
Huawei Huawei
C. Pignataro C. Pignataro
Cisco Cisco
February 12, 2014 March 4, 2014
MPLS Forwarding Compliance and Performance Requirements MPLS Forwarding Compliance and Performance Requirements
draft-ietf-mpls-forwarding-08 draft-ietf-mpls-forwarding-09
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 August 16, 2014. This Internet-Draft will expire on September 5, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
skipping to change at page 2, line 30 skipping to change at page 2, line 25
Table of Contents Table of Contents
1. Introduction and Document Scope . . . . . . . . . . . . . . . 3 1. Introduction and Document Scope . . . . . . . . . . . . . . . 3
1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . 13 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) . . . . . . . . . . . . . . . 16 2.1.7. MPLS Fast Reroute (FRR) . . . . . . . . . . . . . . . 15
2.1.8. Pseudowire Encapsulation . . . . . . . . . . . . . . 16 2.1.8. Pseudowire Encapsulation . . . . . . . . . . . . . . 17
2.1.8.1. Pseudowire Sequence Number . . . . . . . . . . . 17 2.1.8.1. Pseudowire Sequence Number . . . . . . . . . . . 17
2.1.9. Layer-2 and Layer-3 VPN . . . . . . . . . . . . . . . 18 2.1.9. Layer-2 and Layer-3 VPN . . . . . . . . . . . . . . . 19
2.2. MPLS Multicast . . . . . . . . . . . . . . . . . . . . . 19 2.2. MPLS Multicast . . . . . . . . . . . . . . . . . . . . . 19
2.3. Packet Rates . . . . . . . . . . . . . . . . . . . . . . 20 2.3. Packet Rates . . . . . . . . . . . . . . . . . . . . . . 20
2.4. MPLS Multipath Techniques . . . . . . . . . . . . . . . . 21 2.4. MPLS Multipath Techniques . . . . . . . . . . . . . . . . 22
2.4.1. Pseudowire Control Word . . . . . . . . . . . . . . . 22 2.4.1. Pseudowire Control Word . . . . . . . . . . . . . . . 23
2.4.2. Large Microflows . . . . . . . . . . . . . . . . . . 23 2.4.2. Large Microflows . . . . . . . . . . . . . . . . . . 23
2.4.3. Pseudowire Flow Label . . . . . . . . . . . . . . . . 23 2.4.3. Pseudowire Flow Label . . . . . . . . . . . . . . . . 24
2.4.4. MPLS Entropy Label . . . . . . . . . . . . . . . . . 24 2.4.4. MPLS Entropy Label . . . . . . . . . . . . . . . . . 24
2.4.5. Fields Used for Multipath Load Balance . . . . . . . 24 2.4.5. Fields Used for Multipath Load Balance . . . . . . . 25
2.4.5.1. MPLS Fields in Multipath . . . . . . . . . . . . 24 2.4.5.1. MPLS Fields in Multipath . . . . . . . . . . . . 25
2.4.5.2. IP Fields in Multipath . . . . . . . . . . . . . 26 2.4.5.2. IP Fields in Multipath . . . . . . . . . . . . . 27
2.4.5.3. Fields Used in Flow Label . . . . . . . . . . . . 28 2.4.5.3. Fields Used in Flow Label . . . . . . . . . . . . 28
2.4.5.4. Fields Used in Entropy Label . . . . . . . . . . 28 2.4.5.4. Fields Used in Entropy Label . . . . . . . . . . 29
2.5. MPLS-TP and UHP . . . . . . . . . . . . . . . . . . . . . 29 2.5. MPLS-TP and UHP . . . . . . . . . . . . . . . . . . . . . 29
2.6. Local Delivery of Packets . . . . . . . . . . . . . . . . 29 2.6. Local Delivery of Packets . . . . . . . . . . . . . . . . 29
2.6.1. DoS Protection . . . . . . . . . . . . . . . . . . . 29 2.6.1. DoS Protection . . . . . . . . . . . . . . . . . . . 30
2.6.2. MPLS OAM . . . . . . . . . . . . . . . . . . . . . . 31 2.6.2. MPLS OAM . . . . . . . . . . . . . . . . . . . . . . 32
2.6.3. Pseudowire OAM . . . . . . . . . . . . . . . . . . . 32 2.6.3. Pseudowire OAM . . . . . . . . . . . . . . . . . . . 33
2.6.4. MPLS-TP OAM . . . . . . . . . . . . . . . . . . . . . 33 2.6.4. MPLS-TP OAM . . . . . . . . . . . . . . . . . . . . . 33
2.6.5. MPLS OAM and Layer-2 OAM Interworking . . . . . . . . 34 2.6.5. MPLS OAM and Layer-2 OAM Interworking . . . . . . . . 35
2.6.6. Extent of OAM Support by Hardware . . . . . . . . . . 35 2.6.6. Extent of OAM Support by Hardware . . . . . . . . . . 35
2.6.7. Support for IPFIX in Hardware . . . . . . . . . . . . 36
2.7. Number and Size of Flows . . . . . . . . . . . . . . . . 36 2.7. Number and Size of Flows . . . . . . . . . . . . . . . . 36
3. Questions for Suppliers . . . . . . . . . . . . . . . . . . . 36 3. Questions for Suppliers . . . . . . . . . . . . . . . . . . . 37
3.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . 36 3.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . 37
3.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 38 3.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 39
3.3. Multipath Capabilities and Performance . . . . . . . . . 39 3.3. Multipath Capabilities and Performance . . . . . . . . . 40
3.4. Pseudowire Capabilities and Performance . . . . . . . . . 39 3.4. Pseudowire Capabilities and Performance . . . . . . . . . 40
3.5. Entropy Label Support and Performance . . . . . . . . . . 40 3.5. Entropy Label Support and Performance . . . . . . . . . . 41
3.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . 40 3.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . 41
3.7. OAM Capabilities and Performance . . . . . . . . . . . . 40 3.7. OAM Capabilities and Performance . . . . . . . . . . . . 41
4. Forwarding Compliance and Performance Testing . . . . . . . . 41 4. Forwarding Compliance and Performance Testing . . . . . . . . 42
4.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . 41 4.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . 42
4.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 42 4.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 43
4.3. Multipath Capabilities and Performance . . . . . . . . . 42 4.3. Multipath Capabilities and Performance . . . . . . . . . 44
4.4. Pseudowire Capabilities and Performance . . . . . . . . . 43 4.4. Pseudowire Capabilities and Performance . . . . . . . . . 44
4.5. Entropy Label Support and Performance . . . . . . . . . . 44 4.5. Entropy Label Support and Performance . . . . . . . . . . 45
4.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . 44 4.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . 46
4.7. OAM Capabilities and Performance . . . . . . . . . . . . 45 4.7. OAM Capabilities and Performance . . . . . . . . . . . . 46
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
7. Security Considerations . . . . . . . . . . . . . . . . . . . 46 7. Security Considerations . . . . . . . . . . . . . . . . . . . 48
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 8. Organization of References Section . . . . . . . . . . . . . 50
8.1. Normative References . . . . . . . . . . . . . . . . . . 49 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 50
8.2. Informative References . . . . . . . . . . . . . . . . . 51 9.1. Normative References . . . . . . . . . . . . . . . . . . 50
Appendix A. Organization of References Section . . . . . . . . . 56 9.2. Informative References . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58
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 4, line 23 skipping to change at page 4, line 19
protocol fields, such as tunneling protocols carried within IP, are protocol fields, such as tunneling protocols carried within IP, are
out of scope. out of scope.
Implementation details are a local matter and are out of scope. Most Implementation details are a local matter and are out of scope. Most
interfaces today operate at 1 Gb/s or greater. It is assumed that interfaces today operate at 1 Gb/s or greater. It is assumed that
all forwarding operations are implemented in specialized forwarding all forwarding operations are implemented in specialized forwarding
hardware rather than on a general purpose processor. This is often hardware rather than on a general purpose processor. This is often
referred to as "fast path" and "slow path" processing. Some referred to as "fast path" and "slow path" processing. Some
recommendations are made regarding implementing control or management recommendations are made regarding implementing control or management
plane functionality in specialized hardware or with limited plane functionality in specialized hardware or with limited
assistance from specialized hardware. This advise is based on assistance from specialized hardware. This advice is based on
expected control or management protocol loads and on the need for expected control or management protocol loads and on the need for
denial of service (DoS) protection. denial of service (DoS) protection.
1.1. Abbreviations 1.1. Abbreviations
The following abbreviations are used. The following abbreviations are used.
AC Attachment Circuit ([RFC3985]) AC Attachment Circuit ([RFC3985])
ACH Associated Channel Header (pseudowires) ACH Associated Channel Header (pseudowires)
skipping to change at page 8, line 19 skipping to change at page 8, line 15
VOQ Virtual Output Queuing (switch fabric design) VOQ Virtual Output Queuing (switch fabric design)
VPN Virtual Private Network VPN Virtual Private Network
WG Working Group WG Working Group
1.2. Use of Requirements Language 1.2. Use of Requirements Language
This document is informational. The upper case [RFC2119] key words This document is informational. The upper case [RFC2119] key words
are not used in this document, except in the following cases. "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are used in
this document in the following cases.
1. RFC 2119 keywords are used where requirements stated in this 1. RFC 2119 keywords are used where requirements stated in this
document are called for in referenced RFCs. In most cases the document are called for in referenced RFCs. In most cases the
RFC containing the requirement is cited within the statement RFC containing the requirement is cited within the statement
using an RFC 2119 keyword. using an RFC 2119 keyword.
2. RFC 2119 keywords are used where explicitly noted that the 2. RFC 2119 keywords are used where explicitly noted that the
keywords indicate that operator experiences indicate a keywords indicate that operator experiences indicate a
requirement, but there are no existing RFC requirements. requirement, but there are no existing RFC requirements.
skipping to change at page 9, line 26 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 non-negotiable requirements of providers. Implementers common non-negotiable requirements of providers. Implementers
may ignore this advice but should consider the risk of doing so. may ignore 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 implementations and system designs 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
skipping to change at page 10, line 13 skipping to change at page 10, line 5
requirements that are often missed. requirements that are often missed.
1. The implementer and system designer SHOULD support adding a 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.
2. 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.
Non-IETF definitions of MPLS exist and these should not be used as
normative texts in place of the relevant IETF RFCs. [RFC5704]
documents incompatibilities between the IETF definition of MPLS and
one such alternative MPLS definition which led to significant issues
in the resulting non-IETF specification.
1.4. Target Audience 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)
skipping to change at page 14, line 17 skipping to change at page 14, line 9
incoming packets and the ability to insert accurate time stamps in incoming packets and the ability to insert accurate time stamps in
outgoing packets. PTP correction which occurs when forwarding outgoing packets. PTP correction which occurs when forwarding
requires updating a timestamp compensation field based on the requires updating a timestamp compensation field based on the
difference between packet arrival at an LSR and packet transmit time difference between packet arrival at an LSR and packet transmit time
at that same LSR. at that same LSR.
Since the label stack depth may vary, hardware should allow a Since the label stack depth may vary, hardware should allow a
timestamp to be placed in an outgoing packet at any specified byte timestamp to be placed in an outgoing packet at any specified byte
position. It may be necessary to modify layer-2 checksums or frame position. It may be necessary to modify layer-2 checksums or frame
check sequences after insertion. PTP and NTP timestamp formats check sequences after insertion. PTP and NTP timestamp formats
differ slightly. If NTP or PTP is carried over UDP/IP or UDP/IP/ differ in such a way as to require different implementations of the
MPLS, the UDP checksum will also have to be updated. timestamp correction. If NTP or PTP is carried over UDP/IP or UDP/IP
/MPLS, the UDP checksum will also have to be updated.
Accurate time synchronization in addition to being generally useful 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
skipping to change at page 15, line 29 skipping to change at page 15, line 21
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
load balancing across parallel links (see Section 2.4), however this load balancing across parallel links (see Section 2.4), however this
depth can be bounded by a provider through use of Entropy Label. depth can be bounded by a provider through use of Entropy Label.
Other creative use of MPLS within the IETF, such as the use of MPLS
label stack in source routing, may result in label stacks that are
considerably deeper than those encountered today.
2.1.5. MPLS Link Bundling 2.1.5. MPLS Link Bundling
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
skipping to change at page 16, line 9 skipping to change at page 15, line 52
designed to provide RSVP-TE connectivity to the edges. This is the designed to provide RSVP-TE connectivity to the edges. This is the
case for envisioned MPLS-TP networks. The use of the MPLS PSC case for envisioned MPLS-TP networks. The use of the MPLS PSC
hierarchy can add at least one additional label to a label stack, hierarchy can add at least one additional label to a label stack,
though it is likely that only one layer of PSC will be used in the though it is likely that only one layer of PSC will be used in the
near future. 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
assistance is needed for detour FRR only if necessary to accomplish assistance is needed for detour FRR only if necessary to accomplish
local repair of a large number of LSP within the 10s of milliseconds local repair of a large number of LSP within the 10s of milliseconds
target. For each affected LSP a swap operation must be reprogrammed target. For each affected LSP a swap operation must be reprogrammed
or otherwise switched over. The use of detour FRR doubles the number or otherwise switched over. The use of detour FRR doubles the number
of LSP terminating at any given hop and will increase the number of of LSP terminating at any given hop and will increase the number of
LSP within a network by a factor dependent on the average detour path LSP within a network by a factor dependent on the average detour path
length. length.
The bypass method makes use of a tunnel that is unused when no fault The bypass method makes use of a tunnel that is unused when no fault
exists but may carry many LSP when a local repair is required. There exists but may carry many LSP when a local repair is required. There
is no presignaling indicating which working LSP will be diverted into is no presignaling indicating which working LSP will be diverted into
any specific bypass LSP. The merge LSR (egress LSR of the bypass any specific bypass LSP. If interface label space is used the bypass
LSP MUST extend one hop beyond the merge point, except if the merge
point is the egress and PHP is used. If the bypass LSP are not
extended in this way, then the merge LSR (egress LSR of the bypass
LSP) MUST use platform label space (as defined in [RFC3031]) so that LSP) MUST use platform label space (as defined in [RFC3031]) so that
an LSP working path on any given interface can be backed up using a an LSP working path on any given interface can be backed up using a
bypass LSP terminating on any other interface. Hardware assistance bypass LSP terminating on any other interface. Hardware assistance
is needed if necessary to accomplish local repair of a large number is needed if necessary to accomplish local repair of a large number
of LSP within the 10s of milliseconds target. For each affected LSP of LSP within the 10s of milliseconds target. For each affected LSP
a swap operation must be reprogrammed or otherwise switched over with a swap operation must be reprogrammed or otherwise switched over with
an additional push of the bypass LSP label. The use of platform an additional push of the bypass LSP label. The use of platform
label space impacts the size of the LSR ILM for LSR with a very large label space impacts the size of the LSR ILM for LSR with a very large
number of interfaces. number of interfaces.
IP/LDP Fast Reroute (IP/LDR FRR) [RFC5714] is also applicable in MPLS
networks. ECMP and Loop-Free Alternates (LFA) [RFC5286] are well
established IP/LDP FRR techniques and were the first methods to be
widely deployed. Work on IP/LDP FRR is ongoing within the IETF
RTGWG. Two topics actively discussed in RTGWG are microloops and
partial coverage of the established techniques in some network
topologies. [RFC5715] covers the topic of IP/LDP Fast Reroute
microloops and microloops prevention. RTGWG has developed additional
IP/LDP FRR techniques to handle coverage concerns. RTGWG is
extending LFA through the use of remote LFA
[I-D.ietf-rtgwg-remote-lfa]. Other techniques that require new
forwarding paths to be established are also under consideration,
including the IPFRR "not-via" technique defined in [RFC6981] and
maximally redundant trees (MRT)
[I-D.ietf-rtgwg-mrt-frr-architecture]. ECMP, LFA (but not remote
LFA) and MRT swap the top label to an alternate MPLS label. The
other methods operate in a similar manner to RFC 4090 facility backup
and push an additional label. IP/LDP FRR methods which push more
than one label have been suggested but are in early discussion.
2.1.8. Pseudowire Encapsulation 2.1.8. Pseudowire Encapsulation
The pseudowire (PW) architecture is defined in [RFC3985]. A The pseudowire (PW) architecture is defined in [RFC3985]. A
pseudowire, when carried over MPLS, adds one or more additional label pseudowire, when carried over MPLS, adds one or more additional label
entries to the MPLS label stack. A PW Control Word is defined in entries to the MPLS label stack. A PW Control Word is defined in
[RFC4385] with motivation for defining the control word in [RFC4928]. [RFC4385] with motivation for defining the control word in [RFC4928].
The PW Associated Channel defined in [RFC4385] is used for OAM in The PW Associated Channel defined in [RFC4385] is used for OAM in
[RFC5085]. The PW Flow Label is defined in [RFC6391] and is [RFC5085]. The PW Flow Label is defined in [RFC6391] and is
discussed further in this document in Section 2.4.3. discussed further in this document in Section 2.4.3.
skipping to change at page 21, line 28 skipping to change at page 21, line 40
LSR can absorb a long sequence of short packets. Even if the output LSR can absorb a long sequence of short packets. Even if the output
is slowed to the point where light congestion occurs, the packets, is slowed to the point where light congestion occurs, the packets,
having cleared the decision process, can make use of larger VOQ or having cleared the decision process, can make use of larger VOQ or
output side buffers and be dealt with according to configured QoS output side buffers and be dealt with according to configured QoS
treatment, rather than dropped completely at random. treatment, rather than dropped completely at random.
These on-chip buffers need not contribute significant delay since These on-chip buffers need not contribute significant delay since
they are only used when the packet decision engine is unable to keep they are only used when the packet decision engine is unable to keep
up, not in response to congestion, plus these buffers are quite up, not in response to congestion, plus these buffers are quite
small. For example, an on-chip buffer capable of handling 4K packets small. For example, an on-chip buffer capable of handling 4K packets
of 64 bytes in length, or 256KB, corresponds to 2 msec on a 10 Mb/s of 64 bytes in length, or 256KB, corresponds to 200 usec on a 10 Gb/s
link and 0.2 usec on a 100 Gb/s link. If the packet decision engine link and 20 usec on a 100 Gb/s link. If the packet decision engine
is capable of handling packets at 90% of the full rate for small is capable of handling packets at 90% of the full rate for small
packets, then the maximum added delay is 0.2 msec and 20 nsec packets, then the maximum added delay is 20 usec and 2 usec
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. These buffers are only needed on high speed
interfaces where it is difficult to process small packets at full
line rate.
Packet rate requirements apply regardless of which network tier 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
skipping to change at page 27, line 40 skipping to change at page 28, line 4
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 [RFC3550], UDP-Lite [RFC3828], SCTP [RFC4960] and such as RTP [RFC3550], UDP-Lite [RFC3828], SCTP [RFC4960] and
DCCP [RFC4340] SHOULD be provided, particularly for edge or DCCP [RFC4340] SHOULD be provided, particularly for edge or
access equipment where additional entropy may be needed. access equipment where additional entropy may be needed.
Equipment SHOULD also use RTP, UDP-lite, SCTP and DCCP headers Equipment SHOULD also use RTP, UDP-lite, SCTP and DCCP headers
when creating an entropy label. 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, for example as used in [RFC5640] for GRE and traffic may need, for example as used in [RFC5640] for GRE and
L2TPv3. The use of tunneling header information is out of scope L2TPv3. The use of tunneling header information is out of scope
for this document. 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.
uncommon to support using payloads of tunneling protocols carried
over IP. Though the use of tunneling protocol header information is Though potentially very useful in some networks, it is uncommon to
out of scope for this document, it is not discouraged. support using payloads of tunneling protocols carried over IP.
Though the use of tunneling protocol header information is out of
scope for this document, it is not discouraged.
2.4.5.3. Fields Used in Flow Label 2.4.5.3. Fields Used in Flow Label
The ingress to a pseudowire (PW) can extract information from the The ingress to a pseudowire (PW) can extract information from the
payload being encapsulated to create a flow label. [RFC6391] payload being encapsulated to create a flow label. [RFC6391]
references IP carried in Ethernet as an example. The Native Service references IP carried in Ethernet as an example. The Native Service
Processing (NSP) function defined in [RFC3985] differs with Processing (NSP) function defined in [RFC3985] differs with
pseudowire type. It is in the NSP function where information for a pseudowire type. It is in the NSP function where information for a
specific type of PW can be extracted for use in a flow label. Which specific type of PW can be extracted for use in a flow label. Which
fields to use for any given PW NSP is out of scope for this document. fields to use for any given PW NSP is out of scope for this document.
skipping to change at page 31, line 17 skipping to change at page 31, line 38
a cryptographic engine and/or rate limits. The second level of a cryptographic engine and/or rate limits. The second level of
filtering passes connected traffic, such as TCP connections filtering passes connected traffic, such as TCP connections
having received at least one authenticated SYN or having been having received at least one authenticated SYN or having been
locally initiated. The second level of filtering only passes locally initiated. The second level of filtering only passes
traffic to specific address and port pairs to be checked for traffic to specific address and port pairs to be checked for
cryptographic authentication. cryptographic authentication.
The cryptographic authentication is generally the last resort in DoS The cryptographic authentication is generally the last resort in DoS
attack mitigation. If a packet must be first sent to a general attack mitigation. If a packet must be first sent to a general
purpose CPU, then sent to a cryptographic engine, a DoS attack is purpose CPU, then sent to a cryptographic engine, a DoS attack is
possible on high speed interfaces. Only where hardware can identify possible on high speed interfaces. Only where hardware can fully
a signature and the portion of packet covered by the signature is process a cryptographic authentication without intervention from a
cryptographic authentication highly beneficial in protecting against general purpose CPU to find the authentication field and to identify
DoS attacks. the portion of packet to run the cryptographic algorithm over is
cryptographic authentication beneficial in protecting against DoS
attacks.
For chips supporting multiple 100 Gb/s interfaces, only a very large For chips supporting multiple 100 Gb/s interfaces, only a very large
number of parallel cryptographic engines can provide the processing number of parallel cryptographic engines can provide the processing
capacity to handle a large scale DoS or distributed DoS (DDoS) capacity to handle a large scale DoS or distributed DoS (DDoS)
attack. For many forwarding chips this much processing power attack. For many forwarding chips this much processing power
requires significant chip real estate and power, and therefore requires significant chip real estate and power, and therefore
reduces system space and power density. For this reason, reduces system space and power density. For this reason,
cryptographic authentication is not considered a viable first line of cryptographic authentication is not considered a viable first line of
defense. defense.
skipping to change at page 36, line 12 skipping to change at page 36, line 22
underscores the importance of having a degree of programmability in underscores the importance of having a degree of programmability in
forwarding hardware. 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.6.7. Support for IPFIX in Hardware
The IPFIX architecture is defined by [RFC5470]. IPFIX supports per
flow statistics. IPFIX infomation elements (IEs) are defined in
[RFC5102] and include IEs for MPLS.
The forwarding chips used in core routers are not optimized for high
touch applications like IPFIX. Often support for IPFIX in core
routers is limited to optional IPFIX metering, which involves a
1-in-N packet sampling, limited filtering support, and redirection to
either an internal CPU or an external interface. The CPU or device
at the other end of the external interface then implements the full
IPFIX filtering and IPFIX collector functionality.
LSR which are intended to be deployed further from the core may
support lower capacity interfaces but support higher touch
applications on the forwarding hardware and may provide dedicated
hardware to support a greater subset IPFIX functionality before
handing off to a general purpose CPU. In some cases, far from the
core the entire IPFIX functionality up to and including the collector
may be implemented in hardware and firmware in the forwarding
silicon. It is also worth noting that at lower speeds a general
purpose CPU may become adequate to implement IPFIX, particularly if
metering is used.
2.7. Number and Size of Flows 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.
skipping to change at page 37, line 23 skipping to change at page 38, line 12
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 PHB? including RFC3270 L-LSP mappings and RFC4124 CT mappings to 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 stamping B. Is the accuracy of timestamp insertion and incoming 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? 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 regarding MPLS hierarchy. See [RFC3443] See Section 2.1.6 regarding MPLS hierarchy. See [RFC3443]
regarding PHP, UHP, and pipe, short-pipe, and uniform models. regarding PHP, UHP, and pipe, short-pipe, and uniform models.
Q#8 Are pseudowire sequence numbers handled correctly? See Q#8 Is FRR supported?
A. Are both "One-to-One Backup" and "Facility Backup" supported?
B. What forms of IPFRR/LDPFRR are supported?
C. How quickly does protection recovery occur?
D. Does protection recovery speed increase when a fault affects
a large numbers of protected LSP, and if so by how much?
See Section 2.1.7.
Q#9 Are pseudowire sequence numbers handled correctly? See
Section 2.1.8.1. Section 2.1.8.1.
Q#9 Is VPN LER functionality handled correctly and without Q#10 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#11 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
are congested? are congested?
b. Is performance limited in high fanout situations? 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#12 Can very small packets be forwarded at full line rate on all
interfaces indefinitely? What limitations exist, and under what interfaces indefinitely? What limitations exist, and under what
circumstances do further limitations come into play (such as circumstances do further limitations come into play (such 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 and Q#13 Customers must decide whether to relax the prior requirement and
to what extent. If the answer to the prior question indicates to what extent. If the answer to the prior question 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 can B. What is the longest burst of full rate small packets that 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 and specific types of packet processing) often impact these rates and
burst sizes. burst sizes.
Q#13 How many pop operations can be supported along with a swap Q#14 How many pop operations can be supported along with a swap
operation at full line rate while maintaining per LSP packet and operation at full line rate while maintaining per LSP packet 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#15 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#16 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#17 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 MPLS Q#18 How many MPLS labels can be included in a hash based on the MPLS
label stack? label stack?
Q#18 Is packet rate performance decreased beyond some number of Q#19 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#20 Can the IP header and payload information below the MPLS stack
be used in the hash? If so, which IP fields, payload types and 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#21 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#22 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 high capacity flows or Q#23 How is multipath performance affected by high capacity flows or
an extremely large number of flows, or by very short lived flows? an 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#24 Is the pseudowire control word supported?
Q#24 What is the maximum rate of pseudowire encapsulation and Q#25 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#26 Does inclusion of a pseudowire control word impact performance?
Q#26 Are flow labels supported? Q#27 Are flow labels supported?
Q#27 If so, what fields are hashed on for the flow label for Q#28 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#29 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#30 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#31 If so, what fields are hashed on for the entropy label?
Q#31 Does adding or removing an entropy label impact packet rate Q#32 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 the Q#33 Can an entropy label be detected in the label stack, used in the
hash, and properly terminate the search for further information hash, and properly terminate the search for further information
to hash on? to hash on?
Q#33 Does using an entropy label have any negative impact on Q#34 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#35 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#36 Have DoS attack tests been performed?
Q#36 Can compromise of an internal computer on a management subnet be Q#37 Can compromise of an internal computer on a management subnet 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#38 What OAM proactive and on-demand mechanisms are supported?
Q#38 What performance limits exist under high proactive monitoring Q#39 What performance limits exist under high proactive monitoring
rates? rates?
Q#39 Can excessively high proactive monitoring rates impact control Q#40 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#41 Ask the prior questions for each of the following.
a. MPLS OAM
b. Pseudowire OAM A. MPLS OAM
c. MPLS-TP OAM B. Pseudowire OAM
d. Layer-2 OAM Interworking C. MPLS-TP OAM
See Section 2.6.2. D. Layer-2 OAM Interworking
See Section 2.6.
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 42, line 15 skipping to change at page 43, line 17
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 increments packet size. Also test with packet sizes in four byte 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 bursts. larger packets. Allow some time for recovery between bursts.
Increase the number of packets in the burst until packets are Increase the number of packets in the burst until 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 small increasing the number of pop operations until forwarding of small
packets at full line rate can no longer be supported. Also check packets at full line rate can no longer be supported. Also check
skipping to change at page 42, line 41 skipping to change at page 43, line 43
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 various IETF MIBs. System 64 bit packet and byte counters in various IETF MIBs. System
developers should consider what counter polling rate is necessary developers should consider what counter polling rate is necessary
to maintain accurate counters and whether those polling rates are to maintain accurate counters and whether those polling rates are
practical. Relevant MIBs for MPLS are discussed in [RFC4221] and practical. Relevant MIBs for MPLS are discussed in [RFC4221] and
[RFC6639]. [RFC6639].
T#7 [RFC6894] provides a good basis for MPLS FRR testing. Similar
testing should be performed to determine restoration times,
however this testing is far more difficult to perform due to the
need for a simulated test topology that is capable of simulating
the signaling used in restoration. The simulated topology should
be comparable with the target deployment in the number of nodes
and links and in resource usage flooding and setup delays. Some
commercial test equipment can support this type of testing.
4.3. Multipath Capabilities and Performance 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#8 Send traffic at a rate well exceeding the capacity of a single
multipath component link, and where entropy exists only below the multipath component link, and where entropy exists only below the
top of stack. If only the top label is used this test will fail top of stack. If only the top label is used this test will fail
immediately. immediately.
T#8 Move the labels with entropy down in the stack until either the T#9 Move the labels with entropy down in the stack until either the
full forwarding rate can no longer be supported or most or all 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#10 Repeat the two tests above with the entropy contained in IP
headers or IP payload fields below the label stack rather than in headers or IP payload fields below the label stack rather than in
the label stack. Test with the set of IP headers or IP payload the label stack. Test with the set of IP headers or IP payload
fields considered relevant to the deployment or to the target fields considered relevant to the deployment or to the target
market. market.
T#10 Determine whether traffic that contains a pseudowire control T#11 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 the MUST NOT be used in the load balancing if the first nibble of 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#12 Determine whether special purpose labels and extended special
purpose labels are excluded from the label stack hash. They MUST purpose labels are excluded from the label stack hash. They MUST
be excluded. be excluded.
T#12 Perform testing in the presence of combinations of: T#13 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 and T#14 Ensure that pseudowire can be set up with a pseudowire label and
pseudowire control word added at ingress and the pseudowire label pseudowire control word added at ingress and the pseudowire 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#15 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#16 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#17 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 word and the pseudowire label, flow label, and pseudowire control word
removed at egress. removed at egress.
T#17 Determine which payload fields are used to create the flow label T#18 Determine which payload fields are used to create the flow label
and whether the set of fields and algorithm provide sufficient and whether the set of fields and algorithm provide sufficient
entropy for load balancing. entropy for load balancing.
T#18 Repeat pseudowire performance tests with flow labels included. T#19 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#20 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#21 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 applicable further down and IP headers or IP payload fields where applicable
should be used. Determine whether the set of fields and should be used. Determine whether the set of fields 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#22 Repeat performance tests under "Basic Performance" when entropy
labels are used, where ingress or egress is the device under test labels are used, where ingress or egress is the device under test
(DUT). (DUT).
T#22 Determine whether an ELI is detected when acting as a midpoint T#23 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#24 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#25 Insure that operations on the TC field when adding and removing
entropy label are correctly carried out. If TC is changed during entropy label are correctly carried out. If TC is changed during
a swap operation, the ability to transfer that change MUST be a swap operation, the ability to transfer that change MUST be
provided. The ability to suppress the transfer of TC MUST also provided. The ability to suppress the transfer of TC MUST also
be provided. See "pipe", "short pipe", and "uniform" models in be provided. See "pipe", "short pipe", and "uniform" models in
[RFC3443]. [RFC3443].
T#25 Repeat performance tests for a midpoint LSR with entropy labels T#26 Repeat performance tests for a 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 determine T#27 Actively attack LSR under high protocol churn load and determine
control plane performance impact or successful DoS under test control plane performance impact or successful DoS 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 management C. Attacks which can be performed from a compromised management
subnet computer, but not one with authentication keys. subnet computer, but not one with authentication keys.
d. Attacks which can be performed from a compromised peer within D. Attacks which can be performed from a compromised peer within
the control plane (internal domain and external domain). the control plane (internal domain and external domain).
Assume that per peering keys and per router ID keys rather Assume that per peering keys and per router ID 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#28 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#29 Verify LSP Ping and LSP Traceroute capability.
T#29 Determine maximum rates of MPLS-TP CC-CV traffic. If CC-CV T#30 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#31 Determine MPLS-TP DM precision.
T#31 Determine MPLS-TP LM accuracy. T#32 Determine MPLS-TP LM accuracy.
T#32 Verify MPLS-TP AIS/RDI and Protection State Coordination (PSC) T#33 Verify MPLS-TP AIS/RDI and Protection State Coordination (PSC)
functionality, protection speed, and AIS/RDI notification speed functionality, protection speed, and AIS/RDI notification speed
when a large number of Management Entities (ME) must be notified when a large number of Management Entities (ME) must be notified
with AIS/RDI. 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.
skipping to change at page 46, line 41 skipping to change at page 47, line 52
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. Loa Anderson provided useful comments and corrections prior to WGLC.
Adrian Farrel provided useful comments and corrections prior as part Adrian Farrel provided useful comments and corrections prior as part
of the AD review. of the AD review.
Discussion with Steve Kent during SecDir review resulted in expansion Discussion with Steve Kent during SecDir review resulted in expansion
of Section 7, briefly summarizing security considerations related to of Section 7, briefly summarizing security considerations related to
forwarding in normative references. Tom Petch pointed out some forwarding in normative references. Tom Petch pointed out some
editorial errors in private email. Al Morton during OpsDir review editorial errors in private email plus an important math error. Al
prompted clarification in the target audience section, suggested more Morton during OpsDir review prompted clarification in the target
clear wording in places, and found numerous editorial errors. audience section, suggested more clear wording in places, and found
numerous editorial errors.
Discussion with Steward Bryant and Alia Atlas as part of IESG review
resulted in coverage of IPFIX and improvements to document coverage
of MPLS FRR, and IP/LDP FRR, plus some corrections to the text
elsewhere.
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.
Discussion of hardware support and other equipment hardening against Discussion of hardware support and other equipment hardening against
DoS attack can be found in Section 2.6.1. Section 3.6 provides a DoS attack can be found in Section 2.6.1. Section 3.6 provides a
list of question regarding DoS to be asked of suppliers. Section 4.6 list of question regarding DoS to be asked of suppliers. Section 4.6
suggests types of testing that can provide some assurance of the suggests types of testing that can provide some assurance of the
effectiveness of supplier DoS hardening claims. effectiveness of supplier DoS hardening claims.
skipping to change at page 49, line 15 skipping to change at page 50, line 30
denial of service attacks, but not a Byzantine security failure in denial of service attacks, but not a Byzantine security failure in
which other network elements are fully compromised. which other network elements are fully compromised.
MPLS security, or lack of, can affect whether traffic can be MPLS security, or lack of, can affect whether traffic can be
misrouted and lost, or intercepted, or intercepted and reinserted (a misrouted and lost, or intercepted, or intercepted and reinserted (a
man-in-the-middle attack) or spoofed. End user applications, man-in-the-middle attack) or spoofed. End user applications,
including control plane and management plane protocols used by the including control plane and management plane protocols used by the
SP, are expected to make use of appropriate end-to-end authentication SP, are expected to make use of appropriate end-to-end authentication
and where appropriate end-to-end encryption. and where appropriate end-to-end encryption.
8. References 8. Organization of References Section
8.1. Normative References The References section is split into Normative and Informative
subsections. References that directly specify forwarding
encapsulations or behaviors are listed as normative. References
which describe signaling only, though normative with respect to
signaling, are listed as informative. They are informative with
respect to MPLS forwarding.
9. References
9.1. Normative References
[I-D.ietf-mpls-psc-updates] [I-D.ietf-mpls-psc-updates]
Osborne, E., "Updates to PSC", draft-ietf-mpls-psc- Osborne, E., "Updates to PSC", draft-ietf-mpls-psc-
updates-01 (work in progress), January 2014. updates-01 (work in progress), January 2014.
[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
skipping to change at page 51, line 24 skipping to change at page 52, line 46
[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", RFC Defect Indication for the MPLS Transport Profile", RFC
6428, November 2011. 6428, November 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 9.2. Informative References
[ACK-compression] [ACK-compression]
, , , "Observations and Dynamics of a Congestion Control , , and , "Observations and Dynamics of a Congestion
Algorithm: The Effects of Two-Way Traffic", Proc. ACM Control Algorithm: The Effects of Two-Way Traffic", Proc.
SIGCOMM, ACM Computer Communications Review (CCR) Vol 21, ACM SIGCOMM, ACM Computer Communications Review (CCR) Vol
No 4, 1991, pp.133-147., 1991. 21, No 4, 1991, pp.133-147., 1991.
[I-D.ietf-mpls-in-udp] [I-D.ietf-mpls-in-udp]
Building, K., Sheth, N., Yong, L., Pignataro, C., and F. Xu, X., Sheth, N., Yong, L., Pignataro, C., and F.
Yongbing, "Encapsulating MPLS in UDP", draft-ietf-mpls-in- Yongbing, "Encapsulating MPLS in UDP", draft-ietf-mpls-in-
udp-05 (work in progress), January 2014. udp-05 (work in progress), January 2014.
[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-rtgwg-mrt-frr-architecture]
Atlas, A., Kebler, R., Envedi, G., Csaszar, A., Tantsura,
J., Konstantynowicz, M., and R. White, "An Architecture
for IP/LDP Fast-Reroute Using Maximally Redundant Trees",
draft-ietf-rtgwg-mrt-frr-architecture-03 (work in
progress), July 2013.
[I-D.ietf-rtgwg-remote-lfa]
Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S.
Ning, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-04
(work in progress), November 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 54, line 5 skipping to change at page 55, line 36
[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.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC
4960, September 2007. 4960, September 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.
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J.
Meyer, "Information Model for IP Flow Information Export",
RFC 5102, January 2008.
[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast
Reroute: Loop-Free Alternates", RFC 5286, September 2008.
[RFC5317] Bryant, S. and L. Andersson, "Joint Working Team (JWT) [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.
[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.
[RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek,
"Architecture for IP Flow Information Export", RFC 5470,
March 2009.
[RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load- [RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load-
Balancing for Mesh Softwires", RFC 5640, August 2009. 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.
[RFC5704] Bryant, S., Morrow, M., and IAB, "Uncoordinated Protocol
Development Considered Harmful", RFC 5704, November 2009.
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC
5714, January 2010.
[RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free
Convergence", RFC 5715, January 2010.
[RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for [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.
[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.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010. Networks", RFC 5920, July 2010.
skipping to change at page 55, line 48 skipping to change at page 58, line 5
[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", RFC Equivalence Classes (FECs) Advertised over IPv6", RFC
6829, January 2013. 6829, January 2013.
[RFC6894] Papneja, R., Vapiwala, S., Karthik, J., Poretsky, S., Rao,
S., and JL. Le Roux, "Methodology for Benchmarking MPLS
Traffic Engineered (MPLS-TE) Fast Reroute Protection", RFC
6894, March 2013.
[RFC6941] Fang, L., Niven-Jenkins, B., Mansfield, S., and R. [RFC6941] Fang, L., Niven-Jenkins, B., Mansfield, S., and R.
Graveman, "MPLS Transport Profile (MPLS-TP) Security Graveman, "MPLS Transport Profile (MPLS-TP) Security
Framework", RFC 6941, April 2013. Framework", RFC 6941, April 2013.
[RFC6981] Bryant, S., Previdi, S., and M. Shand, "A Framework for IP
and MPLS Fast Reroute Using Not-Via Addresses", RFC 6981,
August 2013.
[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 [RFC7074] Berger, L. and J. Meuric, "Revised Definition of the GMPLS
Switching Capability and Type Fields", RFC 7074, November Switching Capability and Type Fields", RFC 7074, November
2013. 2013.
[RFC7079] Del Regno, N. and A. Malis, "The Pseudowire (PW) and [RFC7079] Del Regno, N. and A. Malis, "The Pseudowire (PW) and
Virtual Circuit Connectivity Verification (VCCV) Virtual Circuit Connectivity Verification (VCCV)
Implementation Survey Results", RFC 7079, November 2013. Implementation Survey Results", RFC 7079, November 2013.
Appendix A. Organization of References Section 9.3. URIs
The References section is split into Normative and Informative [1] http://www.iana.org
subsections. References that directly specify forwarding
encapsulations or behaviors are listed as normative. References
which describe signaling only, though normative with respect to
signaling, are listed as informative. They are informative with
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
Juniper Networks Juniper Networks
 End of changes. 134 change blocks. 
169 lines changed or deleted 311 lines changed or added

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