< draft-ietf-mpls-forwarding-00.txt   draft-ietf-mpls-forwarding-01.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: October 18, 2013 Contrail Systems Expires: April 12, 2014 Contrail Systems
S. Amante S. Amante
Level 3 Communications, Inc. Level 3 Communications, Inc.
A. Malis A. Malis
Verizon Verizon
C. Pignataro C. Pignataro
Cisco Cisco
April 16, 2013 October 9, 2013
MPLS Forwarding Compliance and Performance Requirements MPLS Forwarding Compliance and Performance Requirements
draft-ietf-mpls-forwarding-00 draft-ietf-mpls-forwarding-01
Abstract Abstract
This document provides guidelines for implementors 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 implementors might potentially overlook practical highlighted where implementers might potentially overlook practical
requirements which are unstated or underemphasized or are optional requirements which are unstated or under emphasized or are optional
for conformance to RFCs. for conformance to RFCs but are often considered mandatory by
providers.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 18, 2013. This Internet-Draft will expire on April 12, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 21 skipping to change at page 2, line 23
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction and Document Scope . . . . . . . . . . . . . . . 4 1. Introduction and Document Scope . . . . . . . . . . . . . . . 4
1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Use of Requirements Language . . . . . . . . . . . . . . . 8 1.2. Use of Requirements Language . . . . . . . . . . . . . . . 8
1.3. Apparent Misconceptions . . . . . . . . . . . . . . . . . 9 1.3. Apparent Misconceptions . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . . . 11
2.1.1. MPLS Reserved Labels . . . . . . . . . . . . . . . . . 11 2.1.1. MPLS Special Purpose Labels . . . . . . . . . . . . . 12
2.1.2. MPLS Differentiated Services . . . . . . . . . . . . . 12 2.1.2. MPLS Differentiated Services . . . . . . . . . . . . . 12
2.1.3. Time Synchronization . . . . . . . . . . . . . . . . . 13 2.1.3. Time Synchronization . . . . . . . . . . . . . . . . . 13
2.1.4. Uses of Multiple Label Stack Entries . . . . . . . . . 13 2.1.4. Uses of Multiple Label Stack Entries . . . . . . . . . 14
2.1.5. MPLS Link Bundling . . . . . . . . . . . . . . . . . . 14 2.1.5. MPLS Link Bundling . . . . . . . . . . . . . . . . . . 15
2.1.6. MPLS Hierarchy . . . . . . . . . . . . . . . . . . . . 14 2.1.6. MPLS Hierarchy . . . . . . . . . . . . . . . . . . . . 15
2.1.7. MPLS Fast Reroute (FRR) . . . . . . . . . . . . . . . 14 2.1.7. MPLS Fast Reroute (FRR) . . . . . . . . . . . . . . . 15
2.1.8. Pseudowire Encapsulation . . . . . . . . . . . . . . . 15 2.1.8. Pseudowire Encapsulation . . . . . . . . . . . . . . . 16
2.1.8.1. Pseudowire Sequence Number . . . . . . . . . . . . 15 2.1.8.1. Pseudowire Sequence Number . . . . . . . . . . . . 16
2.1.9. Layer-2 and Layer-3 VPN . . . . . . . . . . . . . . . 16 2.1.9. Layer-2 and Layer-3 VPN . . . . . . . . . . . . . . . 17
2.2. MPLS Multicast . . . . . . . . . . . . . . . . . . . . . . 16 2.2. MPLS Multicast . . . . . . . . . . . . . . . . . . . . . . 18
2.3. Packet Rates . . . . . . . . . . . . . . . . . . . . . . . 17 2.3. Packet Rates . . . . . . . . . . . . . . . . . . . . . . . 18
2.4. MPLS Multipath Techniques . . . . . . . . . . . . . . . . 19 2.4. MPLS Multipath Techniques . . . . . . . . . . . . . . . . 20
2.4.1. Pseudowire Control Word . . . . . . . . . . . . . . . 20 2.4.1. Pseudowire Control Word . . . . . . . . . . . . . . . 21
2.4.2. Large Microflows . . . . . . . . . . . . . . . . . . . 20 2.4.2. Large Microflows . . . . . . . . . . . . . . . . . . . 22
2.4.3. Pseudowire Flow Label . . . . . . . . . . . . . . . . 21 2.4.3. Pseudowire Flow Label . . . . . . . . . . . . . . . . 22
2.4.4. MPLS Entropy Label . . . . . . . . . . . . . . . . . . 21 2.4.4. MPLS Entropy Label . . . . . . . . . . . . . . . . . . 22
2.4.5. Fields Used for Multipath . . . . . . . . . . . . . . 22 2.4.5. Fields Used for Multipath Load Balance . . . . . . . . 23
2.4.5.1. MPLS Fields in Multipath . . . . . . . . . . . . . 22 2.4.5.1. MPLS Fields in Multipath . . . . . . . . . . . . . 23
2.4.5.2. IP Fields in Multipath . . . . . . . . . . . . . . 23 2.4.5.2. IP Fields in Multipath . . . . . . . . . . . . . . 25
2.4.5.3. Fields Used in Flow Label . . . . . . . . . . . . 25 2.4.5.3. Fields Used in Flow Label . . . . . . . . . . . . 26
2.4.5.4. Fields Used in Entropy Label . . . . . . . . . . . 25 2.4.5.4. Fields Used in Entropy Label . . . . . . . . . . . 27
2.5. MPLS-TP and UHP . . . . . . . . . . . . . . . . . . . . . 26 2.5. MPLS-TP and UHP . . . . . . . . . . . . . . . . . . . . . 27
2.6. Local Delivery of Packets . . . . . . . . . . . . . . . . 26 2.6. Local Delivery of Packets . . . . . . . . . . . . . . . . 27
2.6.1. DoS Protection . . . . . . . . . . . . . . . . . . . . 26 2.6.1. DoS Protection . . . . . . . . . . . . . . . . . . . . 28
2.6.2. MPLS OAM . . . . . . . . . . . . . . . . . . . . . . . 28 2.6.2. MPLS OAM . . . . . . . . . . . . . . . . . . . . . . . 30
2.6.3. Pseudowire OAM . . . . . . . . . . . . . . . . . . . . 29 2.6.3. Pseudowire OAM . . . . . . . . . . . . . . . . . . . . 31
2.6.4. MPLS-TP OAM . . . . . . . . . . . . . . . . . . . . . 30 2.6.4. MPLS-TP OAM . . . . . . . . . . . . . . . . . . . . . 31
2.6.5. MPLS OAM and Layer-2 OAM Interworking . . . . . . . . 31 2.6.5. MPLS OAM and Layer-2 OAM Interworking . . . . . . . . 32
2.6.6. Extent of OAM Support by Hardware . . . . . . . . . . 32 2.6.6. Extent of OAM Support by Hardware . . . . . . . . . . 33
2.7. Number and Size of Flows . . . . . . . . . . . . . . . . . 32 2.7. Number and Size of Flows . . . . . . . . . . . . . . . . . 34
3. Questions for Suppliers . . . . . . . . . . . . . . . . . . . 33 3. Questions for Suppliers . . . . . . . . . . . . . . . . . . . 34
3.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . . 33 3.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . . 35
3.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 35 3.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 36
3.3. Multipath Capabilities and Performance . . . . . . . . . . 35 3.3. Multipath Capabilities and Performance . . . . . . . . . . 37
3.4. Pseudowire Capabilities and Performance . . . . . . . . . 36 3.4. Pseudowire Capabilities and Performance . . . . . . . . . 37
3.5. Entropy Label Support and Performance . . . . . . . . . . 36 3.5. Entropy Label Support and Performance . . . . . . . . . . 38
3.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . . 37 3.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . . 38
3.7. OAM Capabilities and Performance . . . . . . . . . . . . . 37 3.7. OAM Capabilities and Performance . . . . . . . . . . . . . 38
4. Forwarding Compliance and Performance Testing . . . . . . . . 37 4. Forwarding Compliance and Performance Testing . . . . . . . . 39
4.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . . 38 4.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . . 39
4.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 38 4.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 40
4.3. Multipath Capabilities and Performance . . . . . . . . . . 39 4.3. Multipath Capabilities and Performance . . . . . . . . . . 41
4.4. Pseudowire Capabilities and Performance . . . . . . . . . 40 4.4. Pseudowire Capabilities and Performance . . . . . . . . . 41
4.5. Entropy Label Support and Performance . . . . . . . . . . 40 4.5. Entropy Label Support and Performance . . . . . . . . . . 42
4.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . . 41 4.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . . 43
4.7. OAM Capabilities and Performance . . . . . . . . . . . . . 42 4.7. OAM Capabilities and Performance . . . . . . . . . . . . . 43
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
7. Security Considerations . . . . . . . . . . . . . . . . . . . 43 7. Security Considerations . . . . . . . . . . . . . . . . . . . 44
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45
8.1. Normative References . . . . . . . . . . . . . . . . . . . 43 8.1. Normative References . . . . . . . . . . . . . . . . . . . 45
8.2. Informative References . . . . . . . . . . . . . . . . . . 44 8.2. Informative References . . . . . . . . . . . . . . . . . . 46
Appendix A. Organization of References Section . . . . . . . . . 49 Appendix A. Organization of References Section . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51
1. Introduction and Document Scope 1. Introduction and Document Scope
The initial purpose of this document was to address concerns raised The initial purpose of this document was to address concerns raised
on the MPLS WG mailing list about shortcomings in implementations of on the MPLS WG mailing list about shortcomings in implementations of
MPLS forwarding. Documenting existing misconceptions and potential MPLS forwarding. Documenting existing misconceptions and potential
pitfalls might potentially avoid repeating past mistakes. The pitfalls might potentially avoid repeating past mistakes. The
document has grown to address a broad set of forwarding requirements. document has grown to address a broad set of forwarding requirements.
The focus of this document is MPLS forwarding, base pseudowire The focus of this document is MPLS forwarding, base pseudowire
skipping to change at page 4, line 33 skipping to change at page 4, line 33
interpret the MPLS payload as IPv4 or IPv6 based on the contents of interpret the MPLS payload as IPv4 or IPv6 based on the contents of
the first nibble of payload. The use of IP addresses, the IP the first nibble of payload. The use of IP addresses, the IP
protocol field, and UDP and TCP port number fields in multipath load protocol field, and UDP and TCP port number fields in multipath load
balancing are considered within scope. The use of any other IP balancing are considered within scope. The use of any other IP
protocol fields, such as tunneling protocols carried within IP, are protocol fields, such as tunneling protocols carried within IP, are
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 special 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 implemeting 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. Acronyms
The following acronyms are used. The following acronyms 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 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)
BFD Bidirectional Forwarding Detection BFD Bidirectional Forwarding Detection
BGP Border Gateway Protocol BGP Border Gateway Protocol
CC-CV Connectivity Check and Connectivity Verification CC-CV Connectivity Check and Connectivity Verification
skipping to change at page 9, line 4 skipping to change at page 9, line 4
"RECOMMENDED", "MAY", and "OPTIONAL" are used only where the "RECOMMENDED", "MAY", and "OPTIONAL" are used only where the
requirement is specified in an existing RFC. These keywords SHOULD requirement is specified in an existing RFC. These keywords SHOULD
be interpreted as described in RFC 2119 [RFC2119]. be interpreted as described in RFC 2119 [RFC2119].
Advice given in this document does not use the upper case RFC 2119 Advice given in this document does not use the upper case RFC 2119
keywords, except where explicitly noted that the keywords indicate keywords, except where explicitly noted that the keywords indicate
that operator experiences indicate a requirement, but there are no that operator experiences indicate a requirement, but there are no
existing RFC requirements. Such advice may be ignored by existing RFC requirements. Such advice may be ignored by
implementations. Similarly, implementations not claiming conformance implementations. Similarly, implementations not claiming conformance
to specific RFCs may ignore the requirements of those RFCs. In both to specific RFCs may ignore the requirements of those RFCs. In both
cases, implementators may be doing so at their own peril. cases, implementers should consider the risk of doing so.
1.3. Apparent Misconceptions 1.3. Apparent Misconceptions
In early generations of forwarding silicon (which might now be behind In early generations of forwarding silicon (which might now be behind
us), there apparently were some misconceptions about MPLS. The us), there apparently were some misconceptions about MPLS. The
following statements provide clarifications. following statements provide clarifications.
1. There are practical reasons to have more than one or two labels 1. There are practical reasons to have more than one or two labels
in an MPLS label stack. Under some circumstances the label stack in an MPLS label stack. Under some circumstances the label stack
can become quite deep. See Section 2.1. can become quite deep. See Section 2.1.
2. The label stack MUST be considered to be arbitrarily deep. 2. The label stack MUST be considered to be arbitrarily deep.
Section 3.27.4. "Hierarchy: LSP Tunnels within LSPs" of RFC 3031 Section 3.27.4. "Hierarchy: LSP Tunnels within LSPs" of RFC3031
[RFC3031] states "The label stack mechanism allows LSP tunneling states "The label stack mechanism allows LSP tunneling to nest to
to nest to any depth." If a bottom of the label stack cannot be any depth." [RFC3031] If a bottom of the label stack cannot be
found, but sufficient number of labels exist to forward, an LSR found, but sufficient number of labels exist to forward, an LSR
MUST forward the packet. An LSR MUST NOT assume the packet is MUST forward the packet. An LSR MUST NOT assume the packet is
malformed unless the end of packet is found before bottom of malformed unless the end of packet is found before bottom of
stack. See Section 2.1. stack. See Section 2.1.
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]. This is due to TCP ACK compression [ACK-compression]. The
following two sub-bullets constitutes advice that reflects very
common hard requirements of providers. Implementers may ignore
this advice but should consider the risk of doing so.
A. A forwarding engine SHOULD, if practical, be able to sustain 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 implementor and system designer MUST support pseudowire 5. The implementer and system designer MUST support pseudowire
control word if MPLS-TP is supported or if ACH is being used on a control word (CW) if MPLS-TP is supported or if ACH [RFC5586] is
pseudowire [RFC5586]. The implementor and system designer SHOULD being used on a pseudowire. The implementer and system designer
support pseudowire control word if MPLS-TP and [RFC5586] are not SHOULD support pseudowire CW even if MPLS-TP and ACH [RFC5586]
used [RFC5085]. Deployments SHOULD enable pseudowire control are not used, using instead CW and VCCV Type 1 [RFC5085] to allow
word. See Section 2.4.1. the use of multipath in the underlying network topology without
impacting the PW traffic.
[I-D.ietf-pwe3-vccv-impl-survey-results] does note that there are
still some deployments where the CW is not always used. It also
notes that many service providers do enable the CW. See
Section 2.4.1 for more discussion on why deployments SHOULD
enable the pseudowire CW.
6. The implementor and system designer SHOULD support adding a 6. The implementer and system designer SHOULD support adding a
pseudowire Flow Label [RFC6391]. Deployments MAY enable this pseudowire Flow Label [RFC6391]. Deployments MAY enable this
feature for appropriate pseudowire types. See Section 2.4.3. feature for appropriate pseudowire types. See Section 2.4.3.
7. The implementor and system designer SHOULD support adding an MPLS 7. The implementer and system designer SHOULD support adding an MPLS
entropy label [RFC6790]. Deployments MAY enable this feature. entropy label [RFC6790]. Deployments MAY enable this feature.
See Section 2.4.4. See Section 2.4.4.
1.4. Target Audience 1.4. Target Audience
This document is intended for multiple audiences: implementor 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: implementor) encountered. (audience: implementer)
2. Highlight pitfalls to look for when implementing an MPLS 2. Highlight pitfalls to look for when implementing an MPLS
forwarding chip. (audience: implementor) forwarding chip. (audience: implementer)
3. Provide a checklist of features and performance specifications to 3. Provide a checklist of features and performance specifications to
request. (audience: systems designer, deployer) request. (audience: systems designer, deployer)
4. Provide a set of tests to perform. (audience: systems designer, 4. Provide a set of tests to perform. (audience: systems designer,
deployer). deployer).
The implementor, systems designer, and deployer have a transitive The implementer, systems designer, and deployer have a transitive
supplier customer relationship. It is in the best interest of the supplier customer relationship. It is in the best interest of the
supplier to review their product against their customer's checklist supplier to review their product against their customer's checklist
and customer's customer's checklist if applicable. and customer's customer's checklist if applicable.
2. Forwarding Issues 2. Forwarding Issues
A brief review of forwarding issues is provided in the subsections A brief review of forwarding issues is provided in the subsections
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 and these requirements exist. The questions to ask of suppliers and
testing is covered in the following sections, Section 3 and testing is covered in the following sections, Section 3 and
skipping to change at page 11, line 40 skipping to change at page 12, line 5
2. The entropy label indicator (ELI) and entropy label (EL) are 2. The entropy label indicator (ELI) and entropy label (EL) are
defined by [RFC6790]. defined by [RFC6790].
A few RFCs update RFC3209. Those that are listed as updating RFC3209 A few RFCs update RFC3209. Those that are listed as updating RFC3209
generally impact only RSVP-TE signaling. Forwarding is modified by generally impact only RSVP-TE signaling. Forwarding is modified by
major extension built upon RFC3209. major extension built upon RFC3209.
RFCs which impact forwarding are discussed in the following RFCs which impact forwarding are discussed in the following
subsections. subsections.
2.1.1. MPLS Reserved Labels 2.1.1. MPLS Special Purpose Labels
[RFC3032] specifies that label values 0-15 are reserved labels with [RFC3032] specifies that label values 0-15 are special purpose labels
special meanings. Three values of NULL label are defined (two of with special meanings. Three values of NULL label are defined (two
which are later updated by [RFC4182]) and a router-alert label is of which are later updated by [RFC4182]) and a router-alert label is
defined. The original intent was that reserved labels, except the defined. The original intent was that special purpose labels, except
NULL labels, could be sent to the routing engine CPU rather than be the NULL labels, could be sent to the routing engine CPU rather than
processed in forwarding hardware. Hardware support is required by be processed in forwarding hardware. Hardware support is required by
new RFCs such as those defining entropy label and OAM processed as a new RFCs such as those defining entropy label and OAM processed as a
result of receiving a GAL. For new reserved labels, some result of receiving a GAL. For new special purpose labels, some
accommodation is needed for LSR that will send the labels to a accommodation is needed for LSR that will send the labels to a
general purpose CPU or other highly programmable hardware. For general purpose CPU or other highly programmable hardware. For
example, ELI will only be sent to LSR which have signaled support for example, ELI will only be sent to LSR which have signaled support for
[RFC6790] and high OAM packet rate must be negotiated among [RFC6790] and high OAM packet rate must be negotiated among
endpoints. endpoints.
[RFC3429] reserves a label for ITU-T Y.1711, however Y.1711 does not [RFC3429] reserves a label for ITU-T Y.1711, however Y.1711 does not
work with multipath and its use is strongly discouraged. work with multipath and its use is strongly discouraged.
The current list of reserved 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 <http://www.iana.org>.
When an unknown reserved label is encountered or a reserved label not [I-D.ietf-mpls-special-purpose-labels] introduces an IANA "Extended
directly handled in forwarding hardware is encountered, the packet Special Purpose MPLS Label Values" registry and makes use of the
should be sent to a general purpose CPU by default. If this "extension" label, label 15, to indicate that the next label is an
capability is supported, there must be an option to either drop or extended special purpose label and requires special handling. The
rate limit such packets on a per reserved label value basis. range of only 16 values for special purpose labels allows a table to
be used. The range of extended special purpose labels with 20 bits
available for use may have to be handled in some other way in the
unlikely event that in the future the range of currently reserved
values 256-1048575 are used. If only the standards action range, 16-
239, and the experimental range, 240-255, are used, then a table of
256 entries can be used.
Unknown special purpose labels and unknown extended special purpose
labels are handled the same. When an unknown special purpose label
is encountered or a special purpose label not directly handled in
forwarding hardware is encountered, the packet should be sent to a
general purpose CPU by default. If this capability is supported,
there must be an option to either drop or rate limit such packets on
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 forum is often called a Quality of
Service (QoS) architecture. Service (QoS) architecture.
skipping to change at page 13, line 5 skipping to change at page 13, line 31
provides a means to support up to eight E-LSP-like mappings of provides a means to support up to eight E-LSP-like mappings of
DSCP to TC. DSCP to TC.
To meet Differentiated Services requirements specified in [RFC3270], To meet Differentiated Services requirements specified in [RFC3270],
the following forwarding requirements must be met. An ingress LER the following forwarding requirements must be met. An ingress LER
MUST be able to select an LSP and then apply a per LSP map of DSCP MUST be able to select an LSP and then apply a per LSP map of DSCP
into TC. A midpoint LSR MUST be able to apply a per LSP map of TC to into TC. A midpoint LSR MUST be able to apply a per LSP map of TC to
PHB. The number of mappings supported will be far less than the PHB. The number of mappings supported will be far less than the
number of LSP supported. number of LSP supported.
To meet Differentiated Services requirements specified in [RFC4124],
the following forwarding requirements must be met. An ingress LER
MUST be able to select an LSP and then apply a per LSP map of DSCP
into TC. A midpoint LSR MUST be able to apply a per LSP map to CT
map and then use Class Type (CT) to map TC to PHB. Since there are
only eight allowed values of CT, only eight maps of TC to PHB need to
be supported. The LSP label can be used directly to find the TC to
PHB mapping, as is needed to support [RFC3270] L-LSP.
While support for [RFC4124] and not [RFC3270] would allow support for
only eight mappings of TC to PHB, it is common to support both and
simply state a limit on the number of unique TC to PHB mappings which
can be supported.
2.1.3. Time Synchronization 2.1.3. Time Synchronization
PTP or NTP may be carried over MPLS [I-D.ietf-tictoc-1588overmpls]. PTP or NTP may be carried over MPLS [I-D.ietf-tictoc-1588overmpls].
Generally NTP will be carried within IP with IP carried in MPLS Generally NTP will be carried within IP with IP carried in MPLS
[RFC5905]. Both PTP and NTP benefit from accurate time stamping of [RFC5905]. Both PTP and NTP benefit from accurate time stamping of
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.
skipping to change at page 13, line 39 skipping to change at page 14, line 31
MPLS deployments in the early part of the prior decade (circa 2000) MPLS deployments in the early part of the prior decade (circa 2000)
tended to support either LDP or RSVP-TE. LDP was favored by some for tended to support either LDP or RSVP-TE. LDP was favored by some for
its ability to scale to a very large number of PE devices at the edge its ability to scale to a very large number of PE devices at the edge
of the network, without adding deployment complexity. RSVP-TE was of the network, without adding deployment complexity. RSVP-TE was
favored, generally in the network core, where traffic engineering favored, generally in the network core, where traffic engineering
and/or fast reroute were considered important. and/or fast reroute were considered important.
Both LDP and RSVP-TE are used simultaneously within major Service Both LDP and RSVP-TE are used simultaneously within major Service
Provider networks using a technique known as "LDP over RSVP-TE Provider networks using a technique known as "LDP over RSVP-TE
Tunneling". This technique allows service providers to carry LDP Tunneling". This technique allows service providers to carry LDP
tunnels, originating and terminating at PE's, inside of RSVP-TE tunnels, originating and terminating at PEs, inside of RSVP-TE
tunnels, generally between Inter-City P routers, to take advantage of tunnels, generally between Inter-City P routers, to take advantage of
Traffic Engineering and Fast Re-Route on more expensive Inter-City Traffic Engineering and Fast Re-Route on more expensive Inter-City
and Inter-Continental Transport paths. LDP over RSVP-TE tunneling and Inter-Continental Transport paths. LDP over RSVP-TE tunneling
requires a minimum of two MPLS labels: one each for LDP and RSVP-TE. requires a minimum of two MPLS labels: one each for LDP and RSVP-TE.
The use of MPLS FRR [RFC4090] might add one more label to MPLS The use of MPLS FRR [RFC4090] might add one more label to MPLS
traffic, but only when FRR protection was in use. If LDP over traffic, but only when FRR protection is in use (active). If LDP
RSVP-TE is in use, and FRR protection is in use, then at least three over RSVP-TE is in use, and FRR protection is in use, then at least
MPLS labels are present on the label stack on the links through which three MPLS labels are present on the label stack on the links through
the Bypass LSP traverses. FRR is covered in Section 2.1.7. which the Bypass LSP traverses. FRR is covered in Section 2.1.7.
LDP L2VPN, LDP IPVPN, BGP L2VPN, and BGP IPVPN added support for VPN LDP L2VPN, LDP IPVPN, BGP L2VPN, and BGP IPVPN added support for VPN
services that are deployed in the vast majority of service providers. services that are deployed in the vast majority of service providers.
These VPN services added yet another label, bringing the label stack These VPN services added yet another label, bringing the label stack
depth (when FRR is active) to four. depth (when FRR is active) to four.
Pseudowires and VPN are discussed in further detail in Section 2.1.8 Pseudowires and VPN are discussed in further detail in Section 2.1.8
and Section 2.1.9. and Section 2.1.9.
MPLS hierarchy as described in [RFC4206] can in principle add up to
four additional labels. MPLS hierarchy is discussed in
Section 2.1.6.
Other features such as Entropy Label (discussed in Section 2.4.4) and
Flow Label (discussed in Section 2.4.3) can add additional labels to
the label stack.
Although theoretical scenarios can easily result in eight or more
labels, such cases are rare if they occur at all today. For the
purpose of forwarding, only the top label needs to be examined if PHP
is used, a few more if UHP is used (see Section 2.5). For deep label
stacks, quite a few labels may have to be examined for the purpose of
load balancing across parallel links (see Section 2.4), however this
depth can be bounded by a provider through use of Entropy Label.
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 14, line 36 skipping to change at page 15, line 44
remains the most likely means of providing further scaling in an remains the most likely means of providing further scaling in an
RSVP-TE MPLS network, particularly where the network is designed to RSVP-TE MPLS network, particularly where the network is designed to
provide RSVP-TE connectivity to the edges. This is the case for provide RSVP-TE connectivity to the edges. This is the case for
envisioned MPLS-TP networks. The use of the MPLS PSC hierarchy can envisioned MPLS-TP networks. The use of the MPLS PSC hierarchy can
add as many as four labels to a label stack, though it is likely that add as many as four labels to a label stack, though it is likely that
only one layer of PSC will be used in the near future. only one layer of PSC will be used in the near future.
2.1.7. MPLS Fast Reroute (FRR) 2.1.7. MPLS Fast Reroute (FRR)
Fast reroute is defined by [RFC4090]. Two significantly different Fast reroute is defined by [RFC4090]. Two significantly different
methods are the "One-to-One Backup" method which uses the "Detour methods are defined in RFC4090, the "One-to-One Backup" method which
LSP" and the " Facility Backup" which uses a "bypass tunnel". These uses the "Detour LSP" and the " Facility Backup" which uses a "bypass
are commonly referred to as the detour and bypass methods tunnel". These are commonly referred to as the detour and bypass
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 egress LSR of the bypass LSP MUST use any specific bypass LSP. The merge LSR (egress LSR of the bypass
platform label space (as defined in [RFC3031]) so that an LSP working LSP) MUST use platform label space (as defined in [RFC3031]) so that
path on any give interface can be backed up using a bypass LSP an LSP working path on any give interface can be backed up using a
terminating on any other interface. Hardware assistance is needed if bypass LSP terminating on any other interface. Hardware assistance
necessary to accomplish local repair of a large number of LSP within is needed if necessary to accomplish local repair of a large number
the 10s of milliseconds target. For each affected LSP a swap of LSP within the 10s of milliseconds target. For each affected LSP
operation must be reprogrammed or otherwise switched over with an a swap operation must be reprogrammed or otherwise switched over with
additional push of the bypass LSP label. In addition the use of an additional push of the bypass LSP label. The use of platform
platform label space impacts the size of the LSR ILM for LSR with a label space impacts the size of the LSR ILM for LSR with a very large
very large number of interfaces. number of interfaces.
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 17, line 17 skipping to change at page 18, line 26
The P2MP LSP have a single source. An LSR may be a leaf node, an The P2MP LSP have a single source. An LSR may be a leaf node, an
intermediate node, or a "bud" node. A bud serves as both a leaf and intermediate node, or a "bud" node. A bud serves as both a leaf and
intermediate. At a leaf an MPLS pop is performed. The payload may intermediate. At a leaf an MPLS pop is performed. The payload may
be a IP Multicast packet that requires further replication. At an be a IP Multicast packet that requires further replication. At an
intermediate node a MPLS swap operation is performed. The bud intermediate node a MPLS swap operation is performed. The bud
requires that both a pop operation and a swap operation be performed requires that both a pop operation and a swap operation be performed
for the same incoming packet. for the same incoming packet.
One strategy to support P2MP functionality is to pop at the LSR One strategy to support P2MP functionality is to pop at the LSR
ingress and then optionally push labels at each LSR egress. A given interface serving as ingress to the P2MP traffic and then optionally
LSR egress chip may support multiple egress interfaces, each of which push labels at each LSR interface serving as egress to the P2MP
requires a copy, but each with a different set of added labels and traffic at that same LSR. A given LSR egress chip may support
layer-2 encapsulation. Some physical interfaces may have multiple multiple egress interfaces, each of which requires a copy, but each
sub-interfaces (such as Ethernet VLAN or channelized interfaces) each with a different set of added labels and layer-2 encapsulation. Some
requiring a copy. physical interfaces may have multiple sub-interfaces (such as
Ethernet VLAN or channelized interfaces) each requiring a copy.
If packet replication is performed at LSR ingress, then the ingress If packet replication is performed at LSR ingress, then the ingress
interface performance may suffer. If the packet replication is interface performance may suffer. If the packet replication is
performed within a LSR switching fabric and at LSR egress, congestion performed within a LSR switching fabric and at LSR egress, congestion
of egress interfaces cannot make use of backpressure to ingress of egress interfaces cannot make use of backpressure to ingress
interfaces using techniques such as virtual output queuing (VOQ). If interfaces using techniques such as virtual output queuing (VOQ). If
buffering is primarily supported at egress, then the need for buffering is primarily supported at egress, then the need for
backpressure is minimized. There may be no good solution for high backpressure is minimized. There may be no good solution for high
volumes of multicast traffic if VOQ is used. volumes of multicast traffic if VOQ is used.
MP2MP LSP differ in that any branch may provide an input, including a MP2MP LSP differ in that any branch may provide an input, including a
leaf. Packets must be replicated onto all other branches. This leaf. Packets must be replicated onto all other branches. This
forwarding is often implemented as multiple P2MP forwarding trees, forwarding is often implemented as multiple P2MP forwarding trees,
one for each potential input. one for each potential input interface at a given LSR.
2.3. Packet Rates 2.3. Packet Rates
While average packet size of Internet traffic may be large, long While average packet size of Internet traffic may be large, long
sequences of small packets have both been predicted in theory and sequences of small packets have both been predicted in theory and
observed in practice. Traffic compression and TCP ACK compression observed in practice. Traffic compression and TCP ACK compression
can conspire to create long sequences of packets of 40-44 bytes in can conspire to create long sequences of packets of 40-44 bytes in
payload length. If carried over Ethernet, the 64 byte minimum payload length. If carried over Ethernet, the 64 byte minimum
payload applies, yielding a packet rate of approximately 150 Mpps payload applies, yielding a packet rate of approximately 150 Mpps
(million packets per second) for the duration of the burst on a (million packets per second) for the duration of the burst on a
nominal 100 Gb/s link. The peak rate is higher for other nominal 100 Gb/s link. The peak rate is higher for other
encapsulations can be as high as 250 Mpps (for example IP or MPLS encapsulations and can be as high as 250 Mpps (for example IP or MPLS
encapsulated using GFP over OTN ODU4). encapsulated using GFP over OTN ODU4).
It is also possible that the packet rates for a minimum payload size, It is also possible that the packet rates for a minimum payload size,
such as 64 byte (64B) payload for Ethernet, is acceptable, but the such as 64 byte (64B) payload for Ethernet, is acceptable, but the
rate declines for other packet sizes, such as 65B payload. There are rate declines for other packet sizes, such as 65B payload. There are
other packet rates of interest besides TCP ACK. For example, a TCP other packet rates of interest besides TCP ACK. For example, a TCP
ACK carried over an Ethernet PW over MPLS over Ethernet may occupy ACK carried over an Ethernet PW over MPLS over Ethernet may occupy
82B or 82B plus an increment of 4B if additional MPLS labels are 82B or 82B plus an increment of 4B if additional MPLS labels are
present. present.
skipping to change at page 18, line 29 skipping to change at page 19, line 39
important, a larger drop for 82B packets. important, a larger drop for 82B packets.
The loss of some TCP ACK packets are not the primary concern when The loss of some TCP ACK packets are not the primary concern when
such a burst occurs. When a burst occurs, any other packets, such a burst occurs. When a burst occurs, any other packets,
regardless of packet length and packet QoS are dropped once on-chip regardless of packet length and packet QoS are dropped once on-chip
input buffers prior to the decision engine are exceeded. Buffers in input buffers prior to the decision engine are exceeded. Buffers in
front of the packet decision engine are often very small or non- front of the packet decision engine are often very small or non-
existent (less than one packet of buffer) causing significant QoS existent (less than one packet of buffer) causing significant QoS
agnostic packet drop. agnostic packet drop.
Internet service providers and content providers generally specify Internet service providers and content providers at one time
full rate forwarding with 40 byte payload packets as a requirement. specified full rate forwarding with 40 byte payload packets as a
This requirement often can be waived if the provider can be convinced requirement. Today, this requirement often can be waived if the
that when long sequence of short packets occur no packets will be provider can be convinced that when long sequence of short packets
dropped. occur no packets will be dropped.
Many equipment suppliers have pointed out that the extra cost in Many equipment suppliers have pointed out that the extra cost in
designing hardware capable of processing the minimum size packets at designing hardware capable of processing the minimum size packets at
full line rate is significant for very high speed interfaces. If full line rate is significant for very high speed interfaces. If
hardware is not capable of processing the minimum size packets at hardware is not capable of processing the minimum size packets at
full line rate, then that hardware MUST be capable of handling large full line rate, then that hardware MUST be capable of handling large
burst of small packets, a condition which is often observed. This burst of small packets, a condition which is often observed. This
level of performance is necessary to meet Differentiated Services level of performance is necessary to meet Differentiated Services
[RFC2475] requirements for without it, packets are lost prior to [RFC2475] requirements for without it, packets are lost prior to
inspection of the IP DSCP field [RFC2474] or MPLS TC field [RFC5462]. inspection of the IP DSCP field [RFC2474] or MPLS TC field [RFC5462].
With adequate on-chip buffers before the packet decision engine, an With adequate on-chip buffers before the packet decision engine, an
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.
skipping to change at page 19, line 19 skipping to change at page 20, line 29
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 2 msec on a 10 Mb/s
link and 0.2 usec on a 100 Gb/s link. If the packet decision engine link and 0.2 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 0.2 msec and 20 nsec
respectively, and this delay only applies if a 4K burst of short respectively, and this delay only applies if a 4K burst of short
packets occurs. When no burst of short packets was being processed, packets occurs. When no burst of short packets was being processed,
no delay is added. no delay is added.
Packet rate requirements apply regardless of which network tier Packet rate requirements apply regardless of which network tier
equipment is deployed in. Whether deployed in the network core or equipment is deployed in. Whether deployed in the network core or
near the network edges, one of the two conditions MUST be met: near the network edges, one of the two conditions MUST be met if
Differentiated Services requirements are to be met:
1. Packets must be processed at full line rate with minimum sized 1. Packets must be processed at full line rate with minimum sized
packets. -OR- packets. -OR-
2. Packets must be processed at a rate well under generally accepted 2. Packets must be processed at a rate well under generally accepted
average packet sizes, with sufficient buffering prior to the average packet sizes, with sufficient buffering prior to the
packet decision engine to accommodate long bursts of small packet decision engine to accommodate long bursts of small
packets. packets.
2.4. MPLS Multipath Techniques 2.4. MPLS Multipath Techniques
skipping to change at page 20, line 14 skipping to change at page 21, line 26
deployed base of edge equipment without the ability to add an entropy deployed base of edge equipment without the ability to add an entropy
label. label.
A generation of edge equipment supporting the ability to add an MPLS A generation of edge equipment supporting the ability to add an MPLS
entropy label is needed before the performance requirements for core entropy label is needed before the performance requirements for core
LSR can be relaxed. However, it is likely that two generations of LSR can be relaxed. However, it is likely that two generations of
deployment in the future will allow core LSR to support full packet deployment in the future will allow core LSR to support full packet
rate only when a relatively small number of MPLS labels need to be rate only when a relatively small number of MPLS labels need to be
inspected before hashing. For now, don't count on it. inspected before hashing. For now, don't count on it.
Common practice today is to reinspect the packet at each LSR and Common practice today is to reinspect the packet at each LSR and use
information from the packet combined with a hash seed that is information from the packet combined plus a hash seed that is
selected by each LSR. Where flow labels or entropy labels are used, selected by each LSR. Where flow labels or entropy labels are used,
a hash seed must be used when creating these labels. a hash seed must be used when creating these labels.
2.4.1. Pseudowire Control Word 2.4.1. Pseudowire Control Word
Within the core of a network some form of multipath is almost certain Within the core of a network some form of multipath is almost certain
to be used. Multipath techniques deployed today are likely to be to be used. Multipath techniques deployed today are likely to be
looking beneath the label stack for an opportunity to hash on IP looking beneath the label stack for an opportunity to hash on IP
addresses. addresses.
skipping to change at page 21, line 25 skipping to change at page 22, line 39
2.4.3. Pseudowire Flow Label 2.4.3. Pseudowire Flow Label
Unlike a pseudowire control word, a pseudowire flow label [RFC6391], Unlike a pseudowire control word, a pseudowire flow label [RFC6391],
is required only for relatively large capacity pseudowires. There is required only for relatively large capacity pseudowires. There
are many cases where a pseudowire flow label makes sense. Any are many cases where a pseudowire flow label makes sense. Any
service such as a VPN which carries IP traffic within a pseudowire service such as a VPN which carries IP traffic within a pseudowire
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). microflow (in [RFC2475] terms) and may result in the types of
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]
in the network core. Prior to the MPLS entropy label core LSR needed at midpoint LSR. Prior to the MPLS entropy label midpoint LSR needed
to inspect the entire label stack and often the IP headers to provide to inspect the entire label stack and often the IP headers to provide
an adequate distribution of traffic when using multipath techniques an adequate distribution of traffic when using multipath techniques
(see Section 2.4.5). With the use of MPLS entropy label, a hash can (see Section 2.4.5). With the use of MPLS entropy label, a hash can
be performed closer to network edges, placed in the label stack, and be performed closer to network edges, placed in the label stack, and
used within the network core. used by midpoint LSR without fully reinspecting the label 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,
but is likely to be required in the edge or the border to the network but is likely to be required in the edge or the border to the network
core. LSR peering with external networks will also need to be able core. LSR peering with external networks will also need to be able
to add an entropy label. to add an entropy label on incoming traffic.
2.4.5. Fields Used for Multipath 2.4.5. Fields Used for Multipath Load Balance
The most common multipath techniques are based on a hash over a set The most common multipath techniques are based on a hash over a set
of fields. Regardless of whether a hash is used or some other method of fields. Regardless of whether a hash is used or some other method
is used, the there is a limited set of fields which can safely be is used, the there is a limited set of fields which can safely be
used for multipath. used for multipath.
2.4.5.1. MPLS Fields in Multipath 2.4.5.1. MPLS Fields in Multipath
If the "outer" or "first" layer of encapsulation is MPLS, then label If the "outer" or "first" layer of encapsulation is MPLS, then label
stack entries are used in the hash. Within a finite amount of time stack entries are used in the hash. Within a finite amount of time
(and for small packets arriving at high speed that time can quite (and for small packets arriving at high speed that time can be quite
limited) only a finite number of label entries can be inspected. limited) only a finite number of label entries can be inspected.
Pipelined or parallel architectures improve this, but the limit is Pipelined or parallel architectures improve this, but the limit is
still finite. still finite.
The following guidelines are provided for use of MPLS fields in The following guidelines are provided for use of MPLS fields in
multipath load balancing. multipath load balancing.
1. Only the 20 bit label field SHOULD be used. The TTL field SHOULD 1. Only the 20 bit label field SHOULD be used. The TTL field SHOULD
NOT be used. The S bit MUST NOT be used. The TC field (formerly NOT be used. The S bit MUST NOT be used. The TC field (formerly
EXP) MUST NOT be used. See below this list for reasons. EXP) MUST NOT be used. See text following this list for reasons.
2. If an ELI label is found, then if the LSR supports entropy label, 2. If an ELI label is found, then if the LSR supports entropy label,
the EL label field in the next label entry (the EL) SHOULD be the EL label field in the next label entry (the EL) SHOULD be
used and label entries below that label SHOULD NOT be used and used and label entries below that label SHOULD NOT be used and
the MPLS payload SHOULD NOT be used. See below this list for the MPLS payload SHOULD NOT be used. See below this list for
reasons. reasons.
3. Reserved labels (label values 0-15) MUST NOT be used. In 3. Special purpose labels (label values 0-15) MUST NOT be used.
particular, GAL and RA MUST NOT be used so that OAM traffic Extended special purpose labels (any label following label 15)
follows the same path as payload packets with the same label MUST NOT be used. In particular, GAL and RA MUST NOT be used so
stack. that OAM traffic follows the same path as payload packets with
the same label stack.
4. The most entropy is generally found in the label stack entries 4. The most entropy is generally found in the label stack entries
near the bottom of the label stack (innermost label, closest to near the bottom of the label stack (innermost label, closest to
S=1 bit). If the entire label stack cannot be used (or entire S=1 bit). If the entire label stack cannot be used (or entire
stack up to an EL), then it is better to use as many labels as stack up to an EL), then it is better to use as many labels as
possible closest to the bottom of stack. possible closest to the bottom of stack.
5. If no ELI is encountered, and the first nibble of payload 5. 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
skipping to change at page 24, line 34 skipping to change at page 25, line 47
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
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 absense 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 other protocols that share a common Layer-4 header such 5. Support for other protocols that share a common Layer-4 header
as RTP, UDP-lite, SCTP and DCCP SHOULD be provided, particularly such as RTP, UDP-lite, SCTP and DCCP SHOULD be provided,
for edge or access equipment where additional entropy may be particularly for edge or access equipment where additional
needed. Equipment SHOULD also use RTP, UDP-lite, SCTP and DCCP entropy may be needed. Equipment SHOULD also use RTP, UDP-lite,
headers when creating an entropy label. SCTP and DCCP headers when creating an entropy label.
6. The following IP header fields should not or must not be used: 6. The following IP header fields should not or must not be used:
A. Similar to avoiding TC in MPLS, the IP DSCP, and ECN bits A. Similar to avoiding TC in MPLS, the IP DSCP, and ECN bits
MUST NOT be used. MUST NOT be used.
B. The IPv4 TTL or IPv6 Hop Count SHOULD NOT be used. B. The IPv4 TTL or IPv6 Hop Count SHOULD NOT be used.
C. Note that the IP TOS field was deprecated ([RFC0791] was C. Note that the IP TOS field was deprecated ([RFC0791] was
updated by [RFC2474]). No part of the IP DSCP field can be updated by [RFC2474]). No part of the IP DSCP field can be
used (formerly IP PREC and IP TOS bits). used (formerly IP PREC and IP TOS bits).
7. Some IP encapsulations support tunneling, such as IP-in-IP, GRE, 7. Some IP encapsulations support tunneling, such as IP-in-IP, GRE,
L2TPv3, and IPSEC. These provide a greater source of entropy L2TPv3, and IPSEC. These provide a greater source of entropy
which some provider networks carrying large amounts of tunneled which some provider networks carrying large amounts of tunneled
traffic may need. The use of tunneling header information is out traffic may need. The use of tunneling header information is out
of scope for this document. of scope for this document.
This document makes the following recommendations. These This document makes the following recommendations. These
recommendations are not required to claim compliance to any existing recommendations are not required to claim compliance to any existing
RFC therefore implementors are free to ignore them, but due to RFC therefore implementers are free to ignore them, but due to
service provider requirements may be doing so at their own peril. service provider requirements should consider the risk of doing so.
The use of IP addresses MUST be supported and TCP and UDP ports The use of IP addresses MUST be supported and TCP and UDP ports
(conditional on the protocol field and properly located) MUST be (conditional on the protocol field and properly located) MUST be
supported. The ability to disable use of UDP and TCP ports MUST be supported. The ability to disable use of UDP and TCP ports MUST be
available. Though potentially very useful in some networks, it is available. Though potentially very useful in some networks, it is
uncommon to support using payloads of tunneling protocols carried uncommon to support using payloads of tunneling protocols carried
over IP. Though the use of tunneling protocol header information is over IP. Though the use of tunneling protocol header information is
out of scope for this document, it is not discouraged. 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
skipping to change at page 27, line 14 skipping to change at page 28, line 32
equipment from denial of service (DoS) attacks is sufficient, equipment from denial of service (DoS) attacks is sufficient,
particularly for high speed interfaces. This problem is not specific particularly for high speed interfaces. This problem is not specific
to MPLS, but is a topic that cannot be ignored when implementing or to MPLS, but is a topic that cannot be ignored when implementing or
evaluating MPLS implementations. evaluating MPLS implementations.
Two types of protections are often cited as primary means of Two types of protections are often cited as primary means of
protecting against attacks of all kinds. protecting against attacks of all kinds.
Isolated Control/Management Traffic Isolated Control/Management Traffic
Control and Management traffic can be carried out-of-band (OOB), Control and Management traffic can be carried out-of-band (OOB),
meaning not intermixed with payload. For MPLS use of G-ACh and meaning not intermixed with payload. For MPLS, use of G-ACh and
GAL to carry control and management traffic provides a means of GAL to carry control and management traffic provides a means of
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
skipping to change at page 27, line 47 skipping to change at page 29, line 18
additional measures can reduce the potential for a minor breach to be additional measures can reduce the potential for a minor breach to be
leveraged to a full network attack. leveraged to a full network attack.
Some of the additional protections are supported by hardware packet Some of the additional protections are supported by hardware packet
filtering. filtering.
GTSM GTSM
[RFC5082] defines a mechanism that uses the IPv4 TTL or IPv6 Hop [RFC5082] defines a mechanism that uses the IPv4 TTL or IPv6 Hop
Limit fields to insure control traffic that can only originate Limit fields to insure control traffic that can only originate
from an immediate neighbor is not forged and originating from a from an immediate neighbor is not forged and originating from a
distant source. GTSM can be applies to many control protocols distant source. GTSM can be applied to many control protocols
which are routable, for example LDP [RFC6720]. which are routable, for example LDP [RFC6720].
IP Filtering IP Filtering
At the very minimum, packet filtering plus classification and use At the very minimum, packet filtering plus classification and use
of multiple queues supporting rate limiting is needed for traffic of multiple queues supporting rate limiting is needed for traffic
that could potentially be sent to a general purpose CPU used as a that could potentially be sent to a general purpose CPU used as a
routing engine. The first level of filtering only allows routing engine. The first level of filtering only allows
connections to be initiated from specific IP prefixes to specific connections to be initiated from specific IP prefixes to specific
destination ports and then preferably passes traffic directly to destination ports and then preferably passes traffic directly to
a cryptographic engine and/or rate limits. The second level of a cryptographic engine and/or rate limits. The second level of
skipping to change at page 28, line 38 skipping to change at page 30, line 5
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.
For some networks the first line of defense is some means of For some networks the first line of defense is some means of
supporting OOB control and management traffic. In the past this OOB supporting OOB control and management traffic. In the past this OOB
channel migh make use of overhead bits in SONET or OTN or a dedicated channel might make use of overhead bits in SONET or OTN or a
DWDM wavelength. G-ACh and GAL provide an alternative OOB mechanism dedicated DWDM wavelength. G-ACh and GAL provide an alternative OOB
which is independent of underlying layers. In other networks, mechanism which is independent of underlying layers. In other
including most IP/MPLS networks, perimeter filtering serves a similar networks, including most IP/MPLS networks, perimeter filtering serves
purpose, though less effective without extreme vigilance. a similar purpose, though less effective without extreme vigilance.
A second line of defense is filtering, including GTSM. For protocols A second line of defense is filtering, including GTSM. For protocols
such as EBGP, GTSM and other filtering is often the first line of such as EBGP, GTSM and other filtering is often the first line of
defense. Cryptographic authentication is usually the last line of defense. Cryptographic authentication is usually the last line of
defense and insufficient by itself to mitigate DoS or DDoS attacks. defense and insufficient by itself to mitigate DoS or DDoS attacks.
2.6.2. MPLS OAM 2.6.2. MPLS OAM
[RFC4377] defines requirements for MPLS OAM that predate MPLS-TP. [RFC4377] defines requirements for MPLS OAM that predate MPLS-TP.
[RFC4379] defines what is commonly referred to as LSP Ping and LSP [RFC4379] defines what is commonly referred to as LSP Ping and LSP
skipping to change at page 29, line 25 skipping to change at page 30, line 41
[RFC5880] defines Bidirectional Forwarding Detection (BFD), a [RFC5880] defines Bidirectional Forwarding Detection (BFD), a
protocol intended to detect faults in the bidirectional path between protocol intended to detect faults in the bidirectional path between
two forwarding engines. [RFC5884] and [RFC5885] define BFD for MPLS. two forwarding engines. [RFC5884] and [RFC5885] define BFD for MPLS.
BFD can provide failure detection on any kind of path between BFD can provide failure detection on any kind of path between
systems, including direct physical links, virtual circuits, tunnels, systems, including direct physical links, virtual circuits, tunnels,
MPLS Label Switched Paths (LSPs), multihop routed paths, and MPLS Label Switched Paths (LSPs), multihop routed paths, and
unidirectional links as long as there is some return path. unidirectional links as long as there is some return path.
The processing requirements for BFD are less than for LSP Ping, The processing requirements for BFD are less than for LSP Ping,
making BFD somewhat better suited for relatively high rate proactive making BFD somewhat better suited for relatively high rate proactive
monitoring. BFD does not verify that the data plane against the monitoring. BFD does not verify that the data plane matches the
control plane, where LSP Ping does. LSP Ping somewhat better suited control plane, where LSP Ping does. LSP Ping is somewhat better
for on-demand monitoring including relatively low rate periodic suited for on-demand monitoring including relatively low rate
verification of data plane and as a diagnostic tool. periodic verification of data plane and as a diagnostic tool.
Hardware assistance is often provided for BFD response where BFD Hardware assistance is often provided for BFD response where BFD
setup or parameter change is not involved and may be necessary for setup or parameter change is not involved and may be necessary for
relatively high rate proactive monitoring. If both BFD and LSP Ping relatively high rate proactive monitoring. If both BFD and LSP Ping
are recognized in filtering prior to passing traffic to a general are recognized in filtering prior to passing traffic to a general
purpose CPU, appropriate DoS protection can be applied (see purpose CPU, appropriate DoS protection can be applied (see
Section 2.6.1). Failure to recognize BFD and LSP Ping and at least Section 2.6.1). Failure to recognize BFD and LSP Ping and at least
rate limit creates the potential for misconfiguration to cause rate limit creates the potential for misconfiguration to cause
outages rather than cause errors in the misconfigured OAM. outages rather than cause errors in the misconfigured OAM.
skipping to change at page 31, line 43 skipping to change at page 33, line 11
OAM solution that is based on Ethernet encodings and mechanisms. OAM solution that is based on Ethernet encodings and mechanisms.
[RFC6310] and [I-D.ietf-pwe3-mpls-eth-oam-iwk] specifies the mapping [RFC6310] and [I-D.ietf-pwe3-mpls-eth-oam-iwk] specifies the mapping
of defect states between many types of hardware Attachment Circuits of defect states between many types of hardware Attachment Circuits
(ACs) and associated Pseudowires (PWs). This functionality SHOULD be (ACs) and associated Pseudowires (PWs). This functionality SHOULD be
supported in forwarding hardware. supported in forwarding hardware.
It is beneficial if an MPLS OAM implementation can interwork with the It is beneficial if an MPLS OAM implementation can interwork with the
underlying server layer and provide a means to interwork with a underlying server layer and provide a means to interwork with a
client layer. For example, [RFC6427] specifies an inter-layer client layer. For example, [RFC6427] specifies an inter-layer
propogation of AIS and LDI from MPLS server layer to client MPLS propagation of AIS and LDI from MPLS server layer to client MPLS
layers. Where the server layer is a Layer-2, such as Ethernet, PPP layers. Where the server layer is a Layer-2, such as Ethernet, PPP
over SONET/SDH, or GFP over OTN, interwork among layers is also over SONET/SDH, or GFP over OTN, interwork among layers is also
beneficial. For high speed interfaces, supporting this interworking beneficial. For high speed interfaces, supporting this interworking
in forwarding hardware helps insure that protection based on this in forwarding hardware helps insure that protection based on this
interworking can meet recovery time requirements even for faults interworking can meet recovery time requirements even for faults
affecting a large number of LSP. affecting a large number of LSP.
2.6.6. Extent of OAM Support by Hardware 2.6.6. Extent of OAM Support by Hardware
Where certain requirements must be met, such as relatively high CC-CV Where certain requirements must be met, such as relatively high CC-CV
skipping to change at page 32, line 41 skipping to change at page 34, line 8
origination of RDI triggered by CC-CV, response to RDI, and PSC origination of RDI triggered by CC-CV, response to RDI, and PSC
functionality may be supported by hardware, but expansion to a large functionality may be supported by hardware, but expansion to a large
number of client LSP and transmission of AIS or RDI to the client LSP number of client LSP and transmission of AIS or RDI to the client LSP
may occur in a general purpose processor. Some forwarding hardware may occur in a general purpose processor. Some forwarding hardware
supports one or more on-chip general purpose processors which may be supports one or more on-chip general purpose processors which may be
well suited for such a role. well suited for such a role.
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 implementors 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.
skipping to change at page 33, line 45 skipping to change at page 35, line 16
Q#1 Can the implementation forward packets with an arbitrarily Q#1 Can the implementation forward packets with an arbitrarily
large stack depth? What limitations exist, and under what large stack depth? What limitations exist, and under what
circumstances do further limitations come into play (such as circumstances do further limitations come into play (such as
high packet rate or specific features enabled or specific types high packet rate or specific features enabled or specific types
of packet processing)? See Section 2.1. of packet processing)? See Section 2.1.
Q#2 Is the entire set of basic MPLS functionality described in Q#2 Is the entire set of basic MPLS functionality described in
Section 2.1 supported? Section 2.1 supported?
Q#3 Are the set of MPLS reserved labels handled correctly and with Q#3 Are the set of MPLS special purpose labels handled correctly
adequate performance? See Section 2.1.1. and with adequate performance? Are extended special purpose
labels handled correctly and with adequate performance? See
Section 2.1.1.
Q#4 Are mappings of label value and TC to PHB handled correctly, Q#4 Are mappings of label value and TC to PHB handled correctly,
including RFC3270 L-LSP mappings and RFC4124 CT mappings to including RFC3270 L-LSP mappings and RFC4124 CT mappings to
PHB? See Section 2.1.2. PHB? 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?
skipping to change at page 36, line 18 skipping to change at page 37, line 32
Q#18 Is packet rate performance decreased beyond some number of Q#18 Is packet rate performance decreased beyond some number of
labels? labels?
Q#19 Can the IP header and payload information below the MPLS stack Q#19 Can the IP header and payload information below the MPLS stack
be used in the hash? If so, which IP fields, payload types and be used in the hash? If so, which IP fields, payload types and
payload fields are supported? payload fields are supported?
Q#20 At what maximum MPLS label stack depth can Bottom of Stack and Q#20 At what maximum MPLS label stack depth can Bottom of Stack and
an IP header appear without impacting packet rate performance? an IP header appear without impacting packet rate performance?
Q#21 Are reserved labels excluded from the label stack hash? See Q#21 Are special purpose labels excluded from the label stack hash?
Section 2.4.5.1. Are extended purpose labels excluded from the label stack hash?
See Section 2.4.5.1.
Q#22 How is multipath performance affected by very large flows or an Q#22 How is multipath performance affected by very large flows or an
extremely large number of flows, or by very short lived flows? extremely large number of flows, or by very short lived flows?
See Section 2.7. See Section 2.7.
3.4. Pseudowire Capabilities and Performance 3.4. Pseudowire Capabilities and Performance
Q#23 Is the pseudowire control word supported? Q#23 Is the pseudowire control word supported?
Q#24 What is the maximum rate of pseudowire encapsulation and Q#24 What is the maximum rate of pseudowire encapsulation and
skipping to change at page 37, line 15 skipping to change at page 38, line 31
Q#32 Can an entropy label be detected in the label stack, used in Q#32 Can an entropy label be detected in the label stack, used in
the hash, and properly terminate the search for further the hash, and properly terminate the search for further
information to hash on? information to hash on?
Q#33 Does using an entropy label have any negative impact on Q#33 Does using an entropy label have any negative impact on
performance? It should have no impact or a positive impact. performance? It should have no impact or a positive impact.
3.6. DoS Protection 3.6. DoS Protection
Q#34 For each control and management plane protocol in use, what Q#34 For each control and management plane protocol in use, what
measures are taken to provide DoS attack hardenning? measures are taken to provide DoS attack hardening?
Q#35 Have DoS attack tests been performed? Q#35 Have DoS attack tests been performed?
Q#36 Can compromise of an internal computer on a management subnet Q#36 Can compromise of an internal computer on a management subnet
be leveraged for any form of attack including DoS attack? be leveraged for any form of attack including DoS attack?
3.7. OAM Capabilities and Performance 3.7. OAM Capabilities and Performance
Q#37 What OAM proactive and on-demand mechanisms are supported? Q#37 What OAM proactive and on-demand mechanisms are supported?
skipping to change at page 40, line 10 skipping to change at page 41, line 30
headers or IP payload fields below the label stack rather than headers or IP payload fields below the label stack rather than
in the label stack. Test with the set of IP headers or IP in the label stack. Test with the set of IP headers or IP
payload fields considered relevant to the deployment or to the payload fields considered relevant to the deployment or to the
target market. target market.
T#10 Determine whether traffic that contains a pseudowire control T#10 Determine whether traffic that contains a pseudowire control
word is interpreted as IP traffic. Information in the payload word is interpreted as IP traffic. Information in the payload
MUST NOT be used in the load balancing if the first nibble of MUST NOT be used in the load balancing if the first nibble of
the packet is not 4 or 6 (IPv4 or IPv6). the packet is not 4 or 6 (IPv4 or IPv6).
T#11 Determine whether reserved labels are excluded from the label T#11 Determine whether special purpose labels and extended special
stack hash. They MUST be excluded. purpose labels are excluded from the label stack hash. They
MUST be excluded.
T#12 Perform testing in the presence of combinations of: T#12 Perform testing in the presence of combinations of:
A. Very large microflows. A. Very large microflows.
B. Relatively short lived high capacity flows. B. Relatively short lived high capacity flows.
C. Extremely large numbers of flows. C. Extremely large numbers of flows.
D. Very short lived small flows. D. Very short lived small flows.
skipping to change at page 42, line 48 skipping to change at page 44, line 21
Paul Doolan provided a brief review resulting in a number of Paul Doolan provided a brief review resulting in a number of
clarifications, most notably regarding on-chip vs. system buffering, clarifications, most notably regarding on-chip vs. system buffering,
100 Gb/s link speed assumptions in the 150 Mpps figure, and handling 100 Gb/s link speed assumptions in the 150 Mpps figure, and handling
of large microflows. Pablo Frank reminded us of the sawtooth effect of large microflows. Pablo Frank reminded us of the sawtooth effect
in PPS vs. packet size graphs, prompting the addition of a few in PPS vs. packet size graphs, prompting the addition of a few
paragraphs on this. Comments from Lou Berger at IETF-85 prompted the paragraphs on this. Comments from Lou Berger at IETF-85 prompted the
addition of Section 2.7. addition of Section 2.7.
Valuable comments were received on the BMWG mailing list. Jay Valuable comments were received on the BMWG mailing list. Jay
Karthik pointed out testing methodology hints that after discussion Karthik pointed out testing methodology hints that after discussion
were deemed out of scope and were removed. were deemed out of scope and were removed but may benefit later work
in BMWG.
Nabil Bitar pointed out the need to cover QoS (Differentiated Nabil Bitar pointed out the need to cover QoS (Differentiated
Services), MPLS multicast (P2MP and MP2MP), and MPLS-TP OAM. Nabil Services), MPLS multicast (P2MP and MP2MP), and MPLS-TP OAM. Nabil
also provided a number of clarifications to the questions and tests also provided a number of clarifications to the questions and tests
in Section 3 and Section 4. in Section 3 and Section 4.
Gregory Mirsky and Thomas Beckhaus provided useful comments during Gregory Mirsky and Thomas Beckhaus provided useful comments during
the MPLS RT review. the MPLS RT review.
Tal Mizrahi provided comments that prompted clarifications regarding Tal Mizrahi provided comments that prompted clarifications regarding
skipping to change at page 43, line 29 skipping to change at page 45, line 4
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.
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 networks that may be rate are needed to affect existing equipment and to affect networks
still vulnerable due to failure to implement adequate protection and that may be still vulnerable due to failure to implement adequate
make this type of denial of service unlikely and make undetectable protection. The extreme data and packet rates make this type of
denial of service of this type impossible. denial of service unlikely and make undetectable denial of service of
this type impossible.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
skipping to change at page 45, line 7 skipping to change at page 46, line 30
"Observations and Dynamics of a Congestion Control "Observations and Dynamics of a Congestion Control
Algorithm: The Effects of Two-Way Traffic", Proc. ACM Algorithm: The Effects of Two-Way Traffic", Proc. ACM
SIGCOMM, ACM Computer Communications Review (CCR) Vol 21, SIGCOMM, ACM Computer Communications Review (CCR) Vol 21,
No 4, 1991, pp.133-147., 1991. No 4, 1991, pp.133-147., 1991.
[ATM-EPD-and-PPD] [ATM-EPD-and-PPD]
"Dynamics of TCP Traffic over ATM Networks", IEEE Journal "Dynamics of TCP Traffic over ATM Networks", IEEE Journal
of Special Areas of Communication Vol 13 No 4, May 1995, of Special Areas of Communication Vol 13 No 4, May 1995,
pp. 633-641., May 1995. pp. 633-641., May 1995.
[I-D.ietf-mpls-special-purpose-labels]
Kompella, K., Andersson, L., and A. Farrel, "Allocating
and Retiring Special Purpose MPLS Labels",
draft-ietf-mpls-special-purpose-labels-03 (work in
progress), July 2013.
[I-D.ietf-pwe3-mpls-eth-oam-iwk] [I-D.ietf-pwe3-mpls-eth-oam-iwk]
Mohan, D., Bitar, N., and A. Sajassi, "MPLS and Ethernet Mohan, D., Bitar, N., Sajassi, A., DeLord, S., Niger, P.,
OAM Interworking", draft-ietf-pwe3-mpls-eth-oam-iwk-07 and R. Qiu, "MPLS and Ethernet OAM Interworking",
(work in progress), January 2013. draft-ietf-pwe3-mpls-eth-oam-iwk-08 (work in progress),
July 2013.
[I-D.ietf-pwe3-vccv-impl-survey-results]
Malis, A., "The Pseudowire (PW) & Virtual Circuit
Connectivity Verification (VCCV) Implementation Survey
Results", draft-ietf-pwe3-vccv-impl-survey-results-03
(work in progress), October 2013.
[I-D.ietf-tictoc-1588overmpls] [I-D.ietf-tictoc-1588overmpls]
Davari, S., Oren, A., Bhatia, M., Roberts, P., and L. Davari, S., Oren, A., Bhatia, M., Roberts, P., and L.
Montini, "Transporting Timing messages over MPLS Montini, "Transporting Timing messages over MPLS
Networks", draft-ietf-tictoc-1588overmpls-04 (work in Networks", draft-ietf-tictoc-1588overmpls-05 (work in
progress), February 2013. progress), June 2013.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981. September 1981.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998. December 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
 End of changes. 66 change blocks. 
181 lines changed or deleted 259 lines changed or added

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