draft-ietf-mpls-forwarding-06.txt   draft-ietf-mpls-forwarding-07.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 01, 2014 Juniper Networks Expires: August 16, 2014 Juniper Networks
S. Amante S. Amante
Apple Inc. Apple Inc.
A. Malis A. Malis
Huawei Huawei
C. Pignataro C. Pignataro
Cisco Cisco
January 28, 2014 February 12, 2014
MPLS Forwarding Compliance and Performance Requirements MPLS Forwarding Compliance and Performance Requirements
draft-ietf-mpls-forwarding-06 draft-ietf-mpls-forwarding-07
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 01, 2014. This Internet-Draft will expire on August 16, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction and Document Scope . . . . . . . . . . . . . . . 3 1. Introduction and Document Scope . . . . . . . . . . . . . . . 3
1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. 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 . . . . . . . . . . . . 12 2.1.2. MPLS Differentiated Services . . . . . . . . . . . . 13
2.1.3. Time Synchronization . . . . . . . . . . . . . . . . 13 2.1.3. Time Synchronization . . . . . . . . . . . . . . . . 13
2.1.4. Uses of Multiple Label Stack Entries . . . . . . . . 14 2.1.4. Uses of Multiple Label Stack Entries . . . . . . . . 14
2.1.5. MPLS Link Bundling . . . . . . . . . . . . . . . . . 15 2.1.5. MPLS Link Bundling . . . . . . . . . . . . . . . . . 15
2.1.6. MPLS Hierarchy . . . . . . . . . . . . . . . . . . . 15 2.1.6. MPLS Hierarchy . . . . . . . . . . . . . . . . . . . 15
2.1.7. MPLS Fast Reroute (FRR) . . . . . . . . . . . . . . . 15 2.1.7. MPLS Fast Reroute (FRR) . . . . . . . . . . . . . . . 16
2.1.8. Pseudowire Encapsulation . . . . . . . . . . . . . . 16 2.1.8. Pseudowire Encapsulation . . . . . . . . . . . . . . 16
2.1.8.1. Pseudowire Sequence Number . . . . . . . . . . . 16 2.1.8.1. Pseudowire Sequence Number . . . . . . . . . . . 17
2.1.9. Layer-2 and Layer-3 VPN . . . . . . . . . . . . . . . 18 2.1.9. Layer-2 and Layer-3 VPN . . . . . . . . . . . . . . . 18
2.2. MPLS Multicast . . . . . . . . . . . . . . . . . . . . . 18 2.2. MPLS Multicast . . . . . . . . . . . . . . . . . . . . . 19
2.3. Packet Rates . . . . . . . . . . . . . . . . . . . . . . 19 2.3. Packet Rates . . . . . . . . . . . . . . . . . . . . . . 20
2.4. MPLS Multipath Techniques . . . . . . . . . . . . . . . . 21 2.4. MPLS Multipath Techniques . . . . . . . . . . . . . . . . 21
2.4.1. Pseudowire Control Word . . . . . . . . . . . . . . . 22 2.4.1. Pseudowire Control Word . . . . . . . . . . . . . . . 22
2.4.2. Large Microflows . . . . . . . . . . . . . . . . . . 23 2.4.2. Large Microflows . . . . . . . . . . . . . . . . . . 23
2.4.3. Pseudowire Flow Label . . . . . . . . . . . . . . . . 23 2.4.3. Pseudowire Flow Label . . . . . . . . . . . . . . . . 23
2.4.4. MPLS Entropy Label . . . . . . . . . . . . . . . . . 23 2.4.4. MPLS Entropy Label . . . . . . . . . . . . . . . . . 24
2.4.5. Fields Used for Multipath Load Balance . . . . . . . 24 2.4.5. Fields Used for Multipath Load Balance . . . . . . . 24
2.4.5.1. MPLS Fields in Multipath . . . . . . . . . . . . 24 2.4.5.1. MPLS Fields in Multipath . . . . . . . . . . . . 24
2.4.5.2. IP Fields in Multipath . . . . . . . . . . . . . 26 2.4.5.2. IP Fields in Multipath . . . . . . . . . . . . . 26
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 . . . . . . . . . . 28
2.5. MPLS-TP and UHP . . . . . . . . . . . . . . . . . . . . . 28 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 . . . . . . . . . . . . . . . . . . . 29
2.6.2. MPLS OAM . . . . . . . . . . . . . . . . . . . . . . 31 2.6.2. MPLS OAM . . . . . . . . . . . . . . . . . . . . . . 31
2.6.3. Pseudowire OAM . . . . . . . . . . . . . . . . . . . 32 2.6.3. Pseudowire OAM . . . . . . . . . . . . . . . . . . . 32
2.6.4. MPLS-TP OAM . . . . . . . . . . . . . . . . . . . . . 32 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 . . . . . . . . 34
2.6.6. Extent of OAM Support by Hardware . . . . . . . . . . 34 2.6.6. Extent of OAM Support by Hardware . . . . . . . . . . 35
2.7. Number and Size of Flows . . . . . . . . . . . . . . . . 35 2.7. Number and Size of Flows . . . . . . . . . . . . . . . . 36
3. Questions for Suppliers . . . . . . . . . . . . . . . . . . . 36 3. Questions for Suppliers . . . . . . . . . . . . . . . . . . . 36
3.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . 36 3.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . 36
3.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 38 3.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 38
3.3. Multipath Capabilities and Performance . . . . . . . . . 38 3.3. Multipath Capabilities and Performance . . . . . . . . . 39
3.4. Pseudowire Capabilities and Performance . . . . . . . . . 39 3.4. Pseudowire Capabilities and Performance . . . . . . . . . 39
3.5. Entropy Label Support and Performance . . . . . . . . . . 39 3.5. Entropy Label Support and Performance . . . . . . . . . . 40
3.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . 40 3.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . 40
3.7. OAM Capabilities and Performance . . . . . . . . . . . . 40 3.7. OAM Capabilities and Performance . . . . . . . . . . . . 40
4. Forwarding Compliance and Performance Testing . . . . . . . . 40 4. Forwarding Compliance and Performance Testing . . . . . . . . 41
4.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . 41 4.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . 41
4.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 41 4.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 42
4.3. Multipath Capabilities and Performance . . . . . . . . . 42 4.3. Multipath Capabilities and Performance . . . . . . . . . 42
4.4. Pseudowire Capabilities and Performance . . . . . . . . . 43 4.4. Pseudowire Capabilities and Performance . . . . . . . . . 43
4.5. Entropy Label Support and Performance . . . . . . . . . . 43 4.5. Entropy Label Support and Performance . . . . . . . . . . 44
4.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . 44 4.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . 44
4.7. OAM Capabilities and Performance . . . . . . . . . . . . 45 4.7. OAM Capabilities and Performance . . . . . . . . . . . . 45
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
7. Security Considerations . . . . . . . . . . . . . . . . . . . 46 7. Security Considerations . . . . . . . . . . . . . . . . . . . 46
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 49
8.1. Normative References . . . . . . . . . . . . . . . . . . 46 8.1. Normative References . . . . . . . . . . . . . . . . . . 49
8.2. Informative References . . . . . . . . . . . . . . . . . 49 8.2. Informative References . . . . . . . . . . . . . . . . . 51
Appendix A. Organization of References Section . . . . . . . . . 54 Appendix A. Organization of References Section . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56
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 27 skipping to change at page 4, line 27
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 advise 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. Acronyms 1.1. Abbreviations
The following acronyms 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)
ACK Acknowledgement (TCP flag and type of TCP packet) ACK Acknowledgement (TCP flag and type of TCP packet)
AIS Alarm Indication Signal (MPLS-TP OAM) AIS Alarm Indication Signal (MPLS-TP OAM)
ATM Asynchronous Transfer Mode (legacy switched circuits) ATM Asynchronous Transfer Mode (legacy switched circuits)
skipping to change at page 6, line 28 skipping to change at page 6, line 28
LDP Label Distribution Protocol ([RFC5036]) LDP Label Distribution Protocol ([RFC5036])
LER Label Edge Router ([RFC3031]) LER Label Edge Router ([RFC3031])
LM Loss Measurement (MPLS-TP OAM) LM Loss Measurement (MPLS-TP OAM)
LSP Label Switched Path ([RFC3031]) LSP Label Switched Path ([RFC3031])
LSR Label Switching Router ([RFC3031]) LSR Label Switching Router ([RFC3031])
MP2MP Multipoint to Point MP2MP Multipoint to Multipoint
MPLS MultiProtocol Label Switching ([RFC3031]) MPLS MultiProtocol Label Switching ([RFC3031])
MPLS-TP MPLS Transport Profile ([RFC5317]) MPLS-TP MPLS Transport Profile ([RFC5317])
Mb/s Megabits per second (million bits per second) Mb/s Megabits per second (million bits per second)
NSP Native Service Processing ([RFC3985]) NSP Native Service Processing ([RFC3985])
NTP Network Time Protocol NTP Network Time Protocol
skipping to change at page 7, line 10 skipping to change at page 7, line 10
P2MP Point to Multi-Point P2MP Point to Multi-Point
PE Provider Edge router (LDP, RSVP-TE, other protocols) PE Provider Edge router (LDP, RSVP-TE, other protocols)
PHB Per-Hop-Behavior ([RFC2475]) PHB Per-Hop-Behavior ([RFC2475])
PHP Penultimate Hop Popping ([RFC3443]) PHP Penultimate Hop Popping ([RFC3443])
POS Packet over SONET POS Packet over SONET
PSC This acronym has multiple interpretations. PSC This abbreviation 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 ([RFC6378]) 3. Protection State Coordination ([RFC6378])
PTP Precision Time Protocol PTP Precision Time Protocol
PW Pseudowire PW Pseudowire
skipping to change at page 9, line 23 skipping to change at page 9, line 23
3. In networks where deep label stacks are encountered, they are not 3. In networks where deep label stacks are encountered, they are not
rare. Full packet rate performance is required regardless of rare. Full packet rate performance is required regardless of
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 non-negotiable requirements of providers. Implementers
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,
skipping to change at page 10, line 36 skipping to change at page 10, line 36
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 secondary customer's checklist if applicable.
This document identifies and explains many details and potential pit-
falls of MPLS forwarding. It is likely that the identified set of
potential pit-falls will later prove to be an incomplete set.
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
that follow. This section provides some background on why some of that follow. This section provides some background on why some of
these requirements exist. The questions to ask of suppliers is these requirements exist. The questions to ask of suppliers is
covered in Section 3. Some guidelines for testing are provided in covered in Section 3. Some guidelines for testing are provided in
Section 4. Section 4.
2.1. Forwarding Basics 2.1. Forwarding Basics
skipping to change at page 12, line 18 skipping to change at page 12, line 26
the labels to a general purpose CPU or other highly programmable the labels to a general purpose CPU or other highly programmable
hardware. For example, ELI will only be sent to LSR which have hardware. For example, ELI will only be sent to LSR which have
signaled support for [RFC6790] and high OAM packet rate must be signaled support for [RFC6790] and high OAM packet rate must be
negotiated among endpoints. negotiated among endpoints.
[RFC3429] reserves a label for ITU-T Y.1711, however Y.1711 does not [RFC3429] reserves a label for ITU-T Y.1711, however Y.1711 does not
work with multipath and its use is strongly discouraged. work with multipath and its use is strongly discouraged.
The current list of special purpose labels can be found on the The current list of special purpose labels can be found on the
"Multiprotocol Label Switching Architecture (MPLS) Label Values" "Multiprotocol Label Switching Architecture (MPLS) Label Values"
registry reachable at IANA's pages at http://www.iana.org. registry reachable at IANA's pages at [1].
[I-D.ietf-mpls-special-purpose-labels] introduces an IANA "Extended [I-D.ietf-mpls-special-purpose-labels] introduces an IANA "Extended
Special Purpose MPLS Label Values" registry and makes use of the Special Purpose MPLS Label Values" registry and makes use of the
"extension" label, label 15, to indicate that the next label is an "extension" label, label 15, to indicate that the next label is an
extended special purpose label and requires special handling. The extended special purpose label and requires special handling. The
range of only 16 values for special purpose labels allows a table to range of only 16 values for special purpose labels allows a table to
be used. The range of extended special purpose labels with 20 bits be used. The range of extended special purpose labels with 20 bits
available for use may have to be handled in some other way in the available for use may have to be handled in some other way in the
unlikely event that in the future the range of currently reserved unlikely event that in the future the range of currently reserved
values 256-1048575 are used. If only the standards action range, values 256-1048575 are used. If only the standards action range,
skipping to change at page 12, line 46 skipping to change at page 13, line 11
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
[RFC2474] deprecates the IP Type of Service (TOS) and IP Precedence [RFC2474] deprecates the IP Type of Service (TOS) and IP Precedence
(Prec) fields and replaces them with the Differentiated Services (Prec) fields and replaces them with the Differentiated Services
Field more commonly known as the Differentiated Services Code Point Field more commonly known as the Differentiated Services Code Point
(DSCP) field. [RFC2475] defines the Differentiated Services (DSCP) field. [RFC2475] defines the Differentiated Services
architecture, which in other forum is often called a Quality of architecture, which in other forums, is often called a Quality of
Service (QoS) architecture. Service (QoS) architecture.
MPLS uses the Traffic Class (TC) field to support Differentiated MPLS uses the Traffic Class (TC) field to support Differentiated
Services [RFC5462]. There are two primary documents describing how Services [RFC5462]. There are two primary documents describing how
DSCP is mapped into TC. DSCP is mapped into TC.
1. [RFC3270] defines E-LSP and L-LSP. E-LSP use a static mapping of 1. [RFC3270] defines E-LSP and L-LSP. E-LSP use a static mapping of
DSCP into TC. L-LSP uses a per LSP mapping of DSCP into TC, with DSCP into TC. L-LSP uses a per LSP mapping of DSCP into TC, with
one PHB Scheduling Class (PSC) per L-LSP. Each PSC can use one PHB Scheduling Class (PSC) per L-LSP. Each PSC can use
multiple Per-Hop Behavior (PHB) values. For example, the Assured multiple Per-Hop Behavior (PHB) values. For example, the Assured
skipping to change at page 16, line 13 skipping to change at page 16, line 27
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. 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 give 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.
2.1.8. Pseudowire Encapsulation 2.1.8. Pseudowire Encapsulation
skipping to change at page 16, line 46 skipping to change at page 17, line 11
The pseudowire encapsulation is out of scope for this document. The pseudowire encapsulation is out of scope for this document.
Pseudowire impact on MPLS forwarding at midpoint LSR is within scope. Pseudowire impact on MPLS forwarding at midpoint LSR is within scope.
The impact on ingress MPLS push and egress MPLS UHP pop are within The impact on ingress MPLS push and egress MPLS UHP pop are within
scope. While pseudowire encapsulation is out of scope, some advice scope. While pseudowire encapsulation is out of scope, some advice
is given on sequence number support. is given on sequence number support.
2.1.8.1. Pseudowire Sequence Number 2.1.8.1. Pseudowire Sequence Number
Pseudowire (PW) sequence number support is most important for PW Pseudowire (PW) sequence number support is most important for PW
payload types with a high expectation of lossless and/or in-order payload types with a high expectation of lossless and/or in-order
delivery. Identifying lost PW packets and exact amount of lost delivery. Identifying lost PW packets and the exact amount of lost
payload is critical for PW services which maintain bit timing, such payload is critical for PW services which maintain bit timing, such
as Time Division Multiplexing (TDM) services since these services as Time Division Multiplexing (TDM) services since these services
MUST compensate lost payload on a bit-for-bit basis. MUST compensate lost payload on a bit-for-bit basis.
With PW services which maintain bit timing, packets that have been With PW services which maintain bit timing, packets that have been
received out of order also MUST be identified and may be either re- received out of order also MUST be identified and MAY be either re-
ordered or dropped. Reordering requires, in addition to sequence ordered or dropped. Resequencing requires, in addition to sequence
numbering, a "reorder buffer" in the egress PE, and ability to numbering, a "reorder buffer" in the egress PE, and ability to
reorder is limited by the depth of this buffer. The down side of reorder is limited by the depth of this buffer. The down side of
maintaining a large reorder buffer is added end-to-end service delay. maintaining a large reorder buffer is added end-to-end service delay.
For PW services which maintain bit timing or any other service where For PW services which maintain bit timing or any other service where
jitter must be bounded, a jitter buffer is always necessary. The jitter must be bounded, a jitter buffer is always necessary. The
jitter buffer is needed regardless of whether reordering is done. In jitter buffer is needed regardless of whether reordering is done. In
order to be effective, a reorder buffer must often be larger than a order to be effective, a reorder buffer must often be larger than a
jitter buffer needs to be creating a tradeoff between reducing loss jitter buffer needs to be creating a tradeoff between reducing loss
and minimizing delay. and minimizing delay.
skipping to change at page 17, line 36 skipping to change at page 17, line 47
MPLS-TP, then this reordering may be acceptable. MPLS-TP, then this reordering may be acceptable.
Reducing jitter is best done by an end-system, given that the Reducing jitter is best done by an end-system, given that the
tradeoff of loss vs delay varies among services. For example with tradeoff of loss vs delay varies among services. For example with
interactive real time services low delay is preferred, while with interactive real time services low delay is preferred, while with
non-interactive (one way) real time services low loss is preferred. non-interactive (one way) real time services low loss is preferred.
The same end-site may be receiving both types of traffic. Regardless The same end-site may be receiving both types of traffic. Regardless
of this, bounded jitter is sometimes a requirement for specific of this, bounded jitter is sometimes a requirement for specific
deployments. deployments.
Packet reorder should be rare except in a small number of Packet reordering should be rare except in a small number of
circumstances, most of which are due to network design or equipment circumstances, most of which are due to network design or equipment
design errors: design errors:
1. The most common case is where reordering is rare, occurring only 1. The most common case is where reordering is rare, occurring only
when a network or equipment fault forces traffic on a new path when a network or equipment fault forces traffic on a new path
with different delay. The packet loss that accompanies a network with different delay. The packet loss that accompanies a network
or equipment fault is generally more disruptive than any or equipment fault is generally more disruptive than any
reordering which may occur. reordering which may occur.
2. A path change can be caused by reasons other than a network or 2. A path change can be caused by reasons other than a network or
skipping to change at page 23, line 49 skipping to change at page 24, line 18
can make use of a pseudowire flow label. can make use of a pseudowire flow label.
Any pseudowire carried over MPLS which makes use of the pseudowire Any pseudowire carried over MPLS which makes use of the pseudowire
control word and does not carry a flow label is in effect a single control word and does not carry a flow label is in effect a single
microflow (in [RFC2475] terms) and may result in the types of microflow (in [RFC2475] terms) and may result in the types of
problems described in Section 2.4.2. problems described in Section 2.4.2.
2.4.4. MPLS Entropy Label 2.4.4. MPLS Entropy Label
The MPLS entropy label simplifies flow group identification [RFC6790] The MPLS entropy label simplifies flow group identification [RFC6790]
at midpoint LSR. Prior to the MPLS entropy label midpoint LSR needed at midpoint LSRs. Prior to the MPLS entropy label midpoint LSRs
to inspect the entire label stack and often the IP headers to provide needed to inspect the entire label stack and often the IP headers to
an adequate distribution of traffic when using multipath techniques provide an adequate distribution of traffic when using multipath
(see Section 2.4.5). With the use of MPLS entropy label, a hash can techniques (see Section 2.4.5). With the use of MPLS entropy label,
be performed closer to network edges, placed in the label stack, and a hash can be performed closer to network edges, placed in the label
used by midpoint LSR without fully reinspecting the label stack and stack, and used by midpoint LSRs without fully reinspecting the label
inspecting the payload. stack and inspecting the payload.
The MPLS entropy label is capable of avoiding full label stack and The MPLS entropy label is capable of avoiding full label stack and
payload inspection within the core where performance levels are most payload inspection within the core where performance levels are most
difficult to achieve (see Section 2.3). The label stack inspection difficult to achieve (see Section 2.3). The label stack inspection
can be terminated as soon as the first entropy label is encountered, can be terminated as soon as the first entropy label is encountered,
which is generally after a small number of labels are inspected. which is generally after a small number of labels are inspected.
In order to provide these benefits in the core, LSR closer to the In order to provide these benefits in the core, LSR closer to the
edge must be capable of adding an entropy label. This support may edge must be capable of adding an entropy label. This support may
not be required in the access tier, the tier closest to the customer, not be required in the access tier, the tier closest to the customer,
skipping to change at page 25, line 24 skipping to change at page 25, line 43
5. The most entropy is generally found in the label stack entries 5. The most entropy is generally found in the label stack entries
near the bottom of the label stack (innermost label, closest to near the bottom of the label stack (innermost label, closest to
S=1 bit). If the entire label stack cannot be used (or entire S=1 bit). If the entire label stack cannot be used (or entire
stack up to an EL), then it is better to use as many labels as stack up to an EL), then it is better to use as many labels as
possible closest to the bottom of stack. possible closest to the bottom of stack.
6. If no ELI is encountered, and the first nibble of payload 6. If no ELI is encountered, and the first nibble of payload
contains a 4 (IPv4) or 6 (IPv6), an implementation SHOULD support contains a 4 (IPv4) or 6 (IPv6), an implementation SHOULD support
the ability to interpret the payload as IPv4 or IPv6 and extract the ability to interpret the payload as IPv4 or IPv6 and extract
and use appropriate fields from the IP headers. This feature is and use appropriate fields from the IP headers. This feature is
considered a hard requirement by many service providers. If considered a non-negotiable requirement by many service
supported, there MUST be a way to disable it (if, for example, PW providers. If supported, there MUST be a way to disable it (if,
without CW are used). This ability to disable this feature is for example, PW without CW are used). This ability to disable
considered a hard requirement by many service providers. this feature is considered a non-negotiable requirement by many
Therefore an implementation has a very strong incentive to service providers. Therefore an implementation has a very strong
support both options. incentive to support both options.
7. A label which is popped at egress (UHP pop) SHOULD NOT be used. 7. A label which is popped at egress (UHP pop) SHOULD NOT be used.
A label which is popped at the penultimate hop (PHP pop) SHOULD A label which is popped at the penultimate hop (PHP pop) SHOULD
be used. be used.
Apparently some chips have made use of the TC (formerly EXP) bits as Apparently some chips have made use of the TC (formerly EXP) bits as
a source of entropy. This is very harmful since it will reorder a source of entropy. This is very harmful since it will reorder
Assured Forwarding (AF) traffic [RFC2597] when a subset does not Assured Forwarding (AF) traffic [RFC2597] when a subset does not
conform to the configured rates and is remarked but not dropped at a conform to the configured rates and is remarked but not dropped at a
prior LSR. Traffic which uses MPLS ECN [RFC5129] can also be prior LSR. Traffic which uses MPLS ECN [RFC5129] can also be
skipping to change at page 26, line 42 skipping to change at page 27, line 16
used. There MAY be an option to reverse the order of these used. There MAY be an option to reverse the order of these
addresses, improving the ability to provide symmetric paths in addresses, improving the ability to provide symmetric paths in
some cases. Many service providers require that both addresses some cases. Many service providers require that both addresses
be used. be used.
2. Implementations SHOULD allow inspection of the IP protocol field 2. Implementations SHOULD allow inspection of the IP protocol field
and use of the UDP or TCP port numbers. For many service and use of the UDP or TCP port numbers. For many service
providers this feature is considered mandatory, particularly for providers this feature is considered mandatory, particularly for
enterprise, data center, or edge equipment. If this feature is enterprise, data center, or edge equipment. If this feature is
provided, it SHOULD be possible to disable use of TCP and UDP provided, it SHOULD be possible to disable use of TCP and UDP
ports. Many service providers consider it a hard requirement ports. Many service providers consider it a non-negotiable
that use of UDP and TCP ports can be disabled. Therefore there requirement that use of UDP and TCP ports can be disabled.
is a stong incentive for implementations to provide both options. Therefore there is a strong incentive for implementations to
provide both options.
3. Equipment suppliers MUST NOT make assumptions that because the IP 3. Equipment suppliers MUST NOT make assumptions that because the IP
version field is equal to 4 (an IPv4 packet) that the IP protocol version field is equal to 4 (an IPv4 packet) that the IP protocol
will either be TCP (IP protocol 6) or UDP (IP protocol 17) and will either be TCP (IP protocol 6) or UDP (IP protocol 17) and
blindly fetch the data at the offset where the TCP or UDP ports blindly fetch the data at the offset where the TCP or UDP ports
would be found. With IPv6, TCP and UDP port numbers are not at would be found. With IPv6, TCP and UDP port numbers are not at
fixed offsets. With IPv4 packets carrying IP options, TCP and fixed offsets. With IPv4 packets carrying IP options, TCP and
UDP port numbers are not at fixed offsets. UDP port numbers are not at fixed offsets.
4. The IPv6 header flow field SHOULD be used. This is the explicit 4. The IPv6 header flow field SHOULD be used. This is the explicit
skipping to change at page 30, line 17 skipping to change at page 30, line 24
isolation from potentially malicious payload. Used alone, the isolation from potentially malicious payload. Used alone, the
compromise of a single node, including a small computer at a compromise of a single node, including a small computer at a
network operations center, could compromise an entire network. network operations center, could compromise an entire network.
Implementations which send all G-ACh/GAL traffic directly to a Implementations which send all G-ACh/GAL traffic directly to a
routing engine CPU are subject to DoS attack as a result of such routing engine CPU are subject to DoS attack as a result of such
a compromise. a compromise.
Cryptographic Authentication Cryptographic Authentication
Cryptographic authentication can very effectively prevent Cryptographic authentication can very effectively prevent
malicious injection of control or management traffic. malicious injection of control or management traffic.
Cryptographic authentication can is some circumstances be subject Cryptographic authentication can in some circumstances be subject
to DoS attack by overwhelming the capacity of the decryption with to DoS attack by overwhelming the capacity of the decryption with
a high volume of malicious traffic. For very low speed a high volume of malicious traffic. For very low speed
interfaces, cryptographic authentication can be performed by the interfaces, cryptographic authentication can be performed by the
general purpose CPU used as a routing engine. For all other general purpose CPU used as a routing engine. For all other
cases, cryptographic hardware may be needed. For very high speed cases, cryptographic hardware may be needed. For very high speed
interfaces, even cryptographic hardware can be overwhelmed. interfaces, even cryptographic hardware can be overwhelmed.
Some control and management protocols are often carried with payload Some control and management protocols are often carried with payload
traffic. This is commonly the case with BGP, T-LDP, and SNMP. It is traffic. This is commonly the case with BGP, T-LDP, and SNMP. It is
often the case with RSVP-TE. Even when carried over G-ACh/GAL often the case with RSVP-TE. Even when carried over G-ACh/GAL
skipping to change at page 36, line 4 skipping to change at page 36, line 13
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.7. Number and Size of Flows 2.7. Number and Size of Flows
Service provider networks may carry up to hundreds of millions of Service provider networks may carry up to hundreds of millions of
flows on 10 Gb/s links. Most flows are very short lived, many under flows on 10 Gb/s links. Most flows are very short lived, many under
a second. A subset of the flows are low capacity and somewhat long a second. A subset of the flows are low capacity and somewhat long
lived. When Internet traffic dominates capacity a very small subset lived. When Internet traffic dominates capacity a very small subset
of flows are high capacity and/or very long lived. of flows are high capacity and/or very long lived.
Two types of limitations with regard to number and size of flows have Two types of limitations with regard to number and size of flows have
been observed. been observed.
1. Some hardware cannot handle some very large flows because of 1. Some hardware cannot handle some high capacity flows because of
internal paths which are limited, such as per packet backplane internal paths which are limited, such as per packet backplane
paths or paths internal or external to chips such as buffer paths or paths internal or external to chips such as buffer
memory paths. Such designs can handle aggregates of smaller memory paths. Such designs can handle aggregates of smaller
flows. Some hardware with acknowledged limitations has been flows. Some hardware with acknowledged limitations has been
successfully deployed but may be increasingly problematic if the successfully deployed but may be increasingly problematic if the
capacity of large microflows in deployed networks continues to capacity of large microflows in deployed networks continues to
grow. grow.
2. Some hardware approaches cannot handle a large number of flows, 2. Some hardware approaches cannot handle a large number of flows,
or a large number of large flows due to attempting to count per or a large number of large flows due to attempting to count per
skipping to change at page 39, line 22 skipping to change at page 39, line 31
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 high capacity flows or
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#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.
skipping to change at page 42, line 25 skipping to change at page 42, line 35
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
to see how many pop operations can be supported before the full to see how many pop operations can be supported before the full
set of counters can no longer be maintained. This requirement is set of counters can no longer be maintained. 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 various IETF MIBs. System
should consider what counter polling rate is necessary to developers should consider what counter polling rate is necessary
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].
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 the multipath component link, and where entropy exists only below the
skipping to change at page 44, line 28 skipping to change at page 44, line 42
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 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 midpoint LSR with entropy labels T#25 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#26 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
skipping to change at page 46, line 25 skipping to change at page 46, line 38
Alexander (Sasha) Vainshtein pointed out errors in Section 2.1.8.1 Alexander (Sasha) Vainshtein pointed out errors in Section 2.1.8.1
and suggested new text which after lengthy discussion resulted in and suggested new text which after lengthy discussion resulted in
restating the summarization of requirements from PWE3 RFCs and more restating the summarization of requirements from PWE3 RFCs and more
clearly stating the benefits and drawbacks of packet resequencing clearly stating the benefits and drawbacks of packet resequencing
based on PW sequence number. based on PW sequence number.
Loa Anderson provided useful comments and corrections prior to WGLC. 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
of Section 7, briefly summarizing security considerations related to
forwarding in normative references. Tom Petch pointed out some
editorial errors in private email. Al Morton during OpsDir review
prompted clarification in the target audience section, suggested more
clear wording in places, and found numerous editorial errors.
6. IANA Considerations 6. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
7. Security Considerations 7. Security Considerations
This document reviews forwarding behavior specified elsewhere and This document reviews forwarding behavior specified elsewhere and
points out compliance and performance requirements. As such it points out compliance and performance requirements. As such it
introduces no new security requirements or concerns. introduces no new security requirements or concerns.
Some advice on hardware support and other equipment hardening against Discussion of hardware support and other equipment hardening against
DoS attack can be found in Section 4.6. 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
suggests types of testing that can provide some assurance of the
effectiveness of supplier DoS hardening claims.
Knowledge of potential performance shortcomings may serve to help new Knowledge of potential performance shortcomings may serve to help new
implementations avoid pitfalls. It is unlikely that such knowledge implementations avoid pitfalls. It is unlikely that such knowledge
could be the basis of new denial of service as these pitfalls are could be the basis of new denial of service as these pitfalls are
already widely known in the service provider community and among already widely known in the service provider community and among
leading equipment suppliers. In practice extreme data and packet leading equipment suppliers. In practice extreme data and packet
rate are needed to affect existing equipment and to affect networks rate are needed to affect existing equipment and to affect networks
that may be still vulnerable due to failure to implement adequate that may be still vulnerable due to failure to implement adequate
protection. The extreme data and packet rates make this type of protection. The extreme data and packet rates make this type of
denial of service unlikely and make undetectable denial of service of denial of service unlikely and make undetectable denial of service of
this type impossible. this type impossible.
The set of normative references each contain security considerations.
A brief summarization of MPLS security considerations applicable to
forwarding follows:
1. MPLS encapsulation does not support an authentication extension.
This is reflected in the security section of [RFC3032].
Documents which clarify MPLS header fields such as TTL
[RFC3443], the explicit null label [RFC4182], renaming EXP to TC
[RFC5462], ECN for MPLS [RFC5129], and MPLS Ethernet
encapsulation [RFC5332] make no changes to security
considerations in [RFC3032].
2. Some cited RFCs are related to Diffserv forwarding. [RFC3270]
refers to MPLS and Diffserv security. [RFC2474] mentions theft
of service and denial of service due to mismarking. [RFC2474]
mentions IPsec interaction, but with MPLS, not being carried by
IP, this type of interaction in [RFC2474] is not relevant.
3. [RFC3209] is cited here due only to make-before-break forwarding
requirements. This is related to resource sharing and the theft
of service and denial of service concerns in [RFC2474] apply.
4. [RFC4090] defines FRR which provides protection but does not add
security concerns. RFC4201 defines link bundling but raises no
additional security concerns.
5. Various OAM control channels are defined in [RFC4385] (PW CW),
[RFC5085] (VCCV), [RFC5586] (G-Ach and GAL). These documents
describe potential abuse of these OAM control channels.
6. [RFC4950] defines ICMP extensions when MPLS TTL expires and
payload is IP. This provides MPLS header information which is
of no use to an IP attacker, but sending this information can be
suppressed through configuration.
7. GTSM [RFC5082] provides a means to improve protection against
high traffic volume spoofing as a form of DoS attack.
8. BFD [RFC5880] [RFC5884] [RFC5885] provides a form of OAM used in
MPLS and MPLS-TP. The security considerations related to the
OAM control channel are relevant. The BFD payload supports
authentication unlike the MPLS encapsulation or MPLS or PW
control channel encapsulation is carried in. Where an IP return
OAM path is used IPsec is suggested as a means of securing the
return path.
9. Other forms of OAM are supported by [RFC6374] [RFC6375] (Loss
and Delay Measurement), [RFC6428] (Connectivity Check/
Verification based on BFD), and [RFC6427] (Fault Management).
The security considerations related to the OAM control channel
are relevant. IP return paths, where used, can be secured with
IPsec.
10. Linear protection is defined by [RFC6378] and updated by
[I-D.ietf-mpls-psc-updates]. Security concerns related to MPLS
encapsulation and OAM control channels apply. Security concerns
reiterate [RFC5920] as applied to protection switching.
11. The PW Flow Label [RFC6391] and MPLS Entropy Label [RFC6790]
affect multipath load balancing. Security concerns reiterate
[RFC5920]. Security impacts would be limited to load
distribution.
MPLS security including data plane security is discussed in greater
detail in [RFC5920] (MPLS/GMPLS Security Framework). The MPLS-TP
security framework [RFC6941] build upon this, focusing largely on the
MPLS-TP OAM additions and OAM channels with some attention given to
using network management in place of control plane setup. In both
security framework documents MPLS is assumed to run within a "trusted
zone", defined as being where a single service provider (SP) has
total operational control over that part of the network.
If control plane security and management plane security are
sufficiently robust, compromise of a single network element may
result in chaos in the data plane anywhere in the network through
denial of service attacks, but not a Byzantine security failure in
which other network elements are fully compromised.
MPLS security, or lack of, can affect whether traffic can be
misrouted and lost, or intercepted, or intercepted and reinserted (a
man-in-the-middle attack) or spoofed. End user applications,
including control plane and management plane protocols used by the
SP, are expected to make use of appropriate end-to-end authentication
and where appropriate end-to-end encryption.
8. References 8. References
8.1. Normative References 8.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.
skipping to change at page 49, line 10 skipping to change at page 51, line 20
[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, November Administration, and Maintenance (OAM)", RFC 6427, 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", RFC Defect Indication for the MPLS Transport Profile", RFC
6428, November 2011. 6428, November 2011.
[RFC6720] Pignataro, C. and R. Asati, "The Generalized TTL Security
Mechanism (GTSM) for the Label Distribution Protocol
(LDP)", RFC 6720, August 2012.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding", L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, November 2012. RFC 6790, November 2012.
8.2. Informative References 8.2. Informative References
[ACK-compression] [ACK-compression]
, , , "Observations and Dynamics of a Congestion Control , , , "Observations and Dynamics of a Congestion Control
Algorithm: The Effects of Two-Way Traffic", Proc. ACM Algorithm: The Effects of Two-Way Traffic", Proc. ACM
SIGCOMM, ACM Computer Communications Review (CCR) Vol 21, SIGCOMM, ACM Computer Communications Review (CCR) Vol 21,
skipping to change at page 52, line 24 skipping to change at page 54, line 28
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.
[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
Networks", RFC 5920, July 2010.
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
D., and S. Mansfield, "Guidelines for the Use of the "OAM" D., and S. Mansfield, "Guidelines for the Use of the "OAM"
Acronym in the IETF", BCP 161, RFC 6291, June 2011. Acronym in the IETF", BCP 161, RFC 6291, June 2011.
[RFC6310] Aissaoui, M., Busschbach, P., Martini, L., Morrow, M., [RFC6310] Aissaoui, M., Busschbach, P., Martini, L., Morrow, M.,
Nadeau, T., and Y(J). Stein, "Pseudowire (PW) Operations, Nadeau, T., and Y(J). Stein, "Pseudowire (PW) Operations,
Administration, and Maintenance (OAM) Message Mapping", Administration, and Maintenance (OAM) Message Mapping",
RFC 6310, July 2011. RFC 6310, July 2011.
[RFC6371] Busi, I. and D. Allan, "Operations, Administration, and [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and
skipping to change at page 53, line 34 skipping to change at page 55, line 39
[RFC6669] Sprecher, N. and L. Fang, "An Overview of the Operations, [RFC6669] Sprecher, N. and L. Fang, "An Overview of the Operations,
Administration, and Maintenance (OAM) Toolset for MPLS- Administration, and Maintenance (OAM) Toolset for MPLS-
Based Transport Networks", RFC 6669, July 2012. Based Transport Networks", RFC 6669, July 2012.
[RFC6670] Sprecher, N. and KY. Hong, "The Reasons for Selecting a [RFC6670] Sprecher, N. and KY. Hong, "The Reasons for Selecting a
Single Solution for MPLS Transport Profile (MPLS-TP) Single Solution for MPLS Transport Profile (MPLS-TP)
Operations, Administration, and Maintenance (OAM)", RFC Operations, Administration, and Maintenance (OAM)", RFC
6670, July 2012. 6670, July 2012.
[RFC6720] Pignataro, C. and R. Asati, "The Generalized TTL Security
Mechanism (GTSM) for the Label Distribution Protocol
(LDP)", RFC 6720, August 2012.
[RFC6829] Chen, M., Pan, P., Pignataro, C., and R. Asati, "Label [RFC6829] Chen, M., Pan, P., Pignataro, C., and R. Asati, "Label
Switched Path (LSP) Ping for Pseudowire Forwarding Switched Path (LSP) Ping for Pseudowire Forwarding
Equivalence Classes (FECs) Advertised over IPv6", RFC Equivalence Classes (FECs) Advertised over IPv6", RFC
6829, January 2013. 6829, January 2013.
[RFC6941] Fang, L., Niven-Jenkins, B., Mansfield, S., and R.
Graveman, "MPLS Transport Profile (MPLS-TP) Security
Framework", RFC 6941, April 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
 End of changes. 48 change blocks. 
70 lines changed or deleted 177 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/