< draft-villamizar-mpls-forwarding-01.txt   draft-villamizar-mpls-forwarding-02.txt >
MPLS C. Villamizar, Ed. MPLS C. Villamizar, Ed.
Internet-Draft OCCNC Internet-Draft OCCNC
Intended status: Informational K. Kompella Intended status: Informational K. Kompella
Expires: August 16, 2013 Contrail Systems Expires: October 1, 2013 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
February 12, 2013 March 30, 2013
MPLS Forwarding Compliance and Performance Requirements MPLS Forwarding Compliance and Performance Requirements
draft-villamizar-mpls-forwarding-01 draft-villamizar-mpls-forwarding-02
Abstract Abstract
This document provides guidelines for implementors regarding MPLS This document provides guidelines for implementors 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 implementors might potentially overlook practical
requirements which are unstated or underemphasized or are optional requirements which are unstated or underemphasized or are optional
for conformance to RFCs. for conformance to RFCs.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 16, 2013. This Internet-Draft will expire on October 1, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction and Document Scope . . . . . . . . . . . . . . . 4
1.1. Use of Requirements Language . . . . . . . . . . . . . . . 4 1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Apparent Misconceptions . . . . . . . . . . . . . . . . . 4 1.2. Use of Requirements Language . . . . . . . . . . . . . . . 8
1.3. Target Audience . . . . . . . . . . . . . . . . . . . . . 5 1.3. Apparent Misconceptions . . . . . . . . . . . . . . . . . 9
2. Forwarding Issues . . . . . . . . . . . . . . . . . . . . . . 6 1.4. Target Audience . . . . . . . . . . . . . . . . . . . . . 10
2.1. Forwarding Basics . . . . . . . . . . . . . . . . . . . . 6 2. Forwarding Issues . . . . . . . . . . . . . . . . . . . . . . 10
2.1.1. MPLS Reserved Labels . . . . . . . . . . . . . . . . . 7 2.1. Forwarding Basics . . . . . . . . . . . . . . . . . . . . 10
2.1.2. MPLS Differentiated Services . . . . . . . . . . . . . 7 2.1.1. MPLS Reserved Labels . . . . . . . . . . . . . . . . . 11
2.1.3. Time Synchronization . . . . . . . . . . . . . . . . . 8 2.1.2. MPLS Differentiated Services . . . . . . . . . . . . . 12
2.1.4. Uses of Multiple Label Stack Entries . . . . . . . . . 8 2.1.3. Time Synchronization . . . . . . . . . . . . . . . . . 13
2.1.5. MPLS Link Bundling . . . . . . . . . . . . . . . . . . 9 2.1.4. Uses of Multiple Label Stack Entries . . . . . . . . . 13
2.1.6. MPLS Hierarchy . . . . . . . . . . . . . . . . . . . . 9 2.1.5. MPLS Link Bundling . . . . . . . . . . . . . . . . . . 14
2.1.7. MPLS Fast Reroute (FRR) . . . . . . . . . . . . . . . 10 2.1.6. MPLS Hierarchy . . . . . . . . . . . . . . . . . . . . 14
2.1.8. Pseudowire Encapsulation . . . . . . . . . . . . . . . 10 2.1.7. MPLS Fast Reroute (FRR) . . . . . . . . . . . . . . . 14
2.1.8.1. Pseudowire Sequence Number . . . . . . . . . . . . 11 2.1.8. Pseudowire Encapsulation . . . . . . . . . . . . . . . 15
2.1.9. Layer-2 and Layer-3 VPN . . . . . . . . . . . . . . . 12 2.1.8.1. Pseudowire Sequence Number . . . . . . . . . . . . 15
2.2. MPLS Multicast . . . . . . . . . . . . . . . . . . . . . . 12 2.1.9. Layer-2 and Layer-3 VPN . . . . . . . . . . . . . . . 16
2.3. Packet Rates . . . . . . . . . . . . . . . . . . . . . . . 13 2.2. MPLS Multicast . . . . . . . . . . . . . . . . . . . . . . 16
2.4. MPLS Multipath Techniques . . . . . . . . . . . . . . . . 14 2.3. Packet Rates . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.1. Pseudowire Control Word . . . . . . . . . . . . . . . 15 2.4. MPLS Multipath Techniques . . . . . . . . . . . . . . . . 19
2.4.2. Large Microflows . . . . . . . . . . . . . . . . . . . 16 2.4.1. Pseudowire Control Word . . . . . . . . . . . . . . . 20
2.4.3. Pseudowire Flow Label . . . . . . . . . . . . . . . . 16 2.4.2. Large Microflows . . . . . . . . . . . . . . . . . . . 20
2.4.4. MPLS Entropy Label . . . . . . . . . . . . . . . . . . 16 2.4.3. Pseudowire Flow Label . . . . . . . . . . . . . . . . 21
2.4.5. Fields Used for Multipath . . . . . . . . . . . . . . 17 2.4.4. MPLS Entropy Label . . . . . . . . . . . . . . . . . . 21
2.4.5.1. MPLS Fields in Multipath . . . . . . . . . . . . . 17 2.4.5. Fields Used for Multipath . . . . . . . . . . . . . . 22
2.4.5.2. IP Fields in Multipath . . . . . . . . . . . . . . 19 2.4.5.1. MPLS Fields in Multipath . . . . . . . . . . . . . 22
2.4.5.3. Fields Used in Flow Label . . . . . . . . . . . . 20 2.4.5.2. IP Fields in Multipath . . . . . . . . . . . . . . 23
2.4.5.4. Fields Used in Entropy Label . . . . . . . . . . . 20 2.4.5.3. Fields Used in Flow Label . . . . . . . . . . . . 25
2.5. MPLS-TP and UHP . . . . . . . . . . . . . . . . . . . . . 21 2.4.5.4. Fields Used in Entropy Label . . . . . . . . . . . 25
2.6. OAM and DoS Protection . . . . . . . . . . . . . . . . . . 21 2.5. MPLS-TP and UHP . . . . . . . . . . . . . . . . . . . . . 26
2.6.1. DoS Protection . . . . . . . . . . . . . . . . . . . . 21 2.6. Local Delivery of Packets . . . . . . . . . . . . . . . . 26
2.6.2. MPLS OAM . . . . . . . . . . . . . . . . . . . . . . . 23 2.6.1. DoS Protection . . . . . . . . . . . . . . . . . . . . 26
2.6.3. Pseudowire OAM . . . . . . . . . . . . . . . . . . . . 24 2.6.2. MPLS OAM . . . . . . . . . . . . . . . . . . . . . . . 28
2.6.4. MPLS-TP OAM . . . . . . . . . . . . . . . . . . . . . 25 2.6.3. Pseudowire OAM . . . . . . . . . . . . . . . . . . . . 29
2.6.5. MPLS OAM and Layer-2 OAM Interworking . . . . . . . . 26 2.6.4. MPLS-TP OAM . . . . . . . . . . . . . . . . . . . . . 30
2.6.6. Extent of OAM Support by Hardware . . . . . . . . . . 26 2.6.5. MPLS OAM and Layer-2 OAM Interworking . . . . . . . . 31
2.6.6. Extent of OAM Support by Hardware . . . . . . . . . . 32
2.7. Number and Size of Flows . . . . . . . . . . . . . . . . . 27 2.7. Number and Size of Flows . . . . . . . . . . . . . . . . . 32
3. Questions for Suppliers . . . . . . . . . . . . . . . . . . . 28 3. Questions for Suppliers . . . . . . . . . . . . . . . . . . . 33
4. Forwarding Compliance and Performance Testing . . . . . . . . 32 3.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . . 33
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37 3.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 35
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 3.3. Multipath Capabilities and Performance . . . . . . . . . . 35
7. Security Considerations . . . . . . . . . . . . . . . . . . . 37 3.4. Pseudowire Capabilities and Performance . . . . . . . . . 36
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.5. Entropy Label Support and Performance . . . . . . . . . . 36
8.1. Normative References . . . . . . . . . . . . . . . . . . . 38 3.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . . 37
8.2. Informative References . . . . . . . . . . . . . . . . . . 39 3.7. OAM Capabilities and Performance . . . . . . . . . . . . . 37
Appendix A. Organization of References Section . . . . . . . . . 43 4. Forwarding Compliance and Performance Testing . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 4.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . . 38
4.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 38
4.3. Multipath Capabilities and Performance . . . . . . . . . . 39
4.4. Pseudowire Capabilities and Performance . . . . . . . . . 40
4.5. Entropy Label Support and Performance . . . . . . . . . . 40
4.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . . 41
4.7. OAM Capabilities and Performance . . . . . . . . . . . . . 42
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
7. Security Considerations . . . . . . . . . . . . . . . . . . . 43
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
8.1. Normative References . . . . . . . . . . . . . . . . . . . 43
8.2. Informative References . . . . . . . . . . . . . . . . . . 44
Appendix A. Organization of References Section . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49
1. Introduction 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.
1.1. Use of Requirements Language The focus of this document is MPLS forwarding, base pseudowire
forwarding, and MPLS OAM. The use of pseudowire control word, and
sequence number are discussed. Specific pseudowire AC and NSP are
out of scope. Specific pseudowire applications, such as various
forms of VPN, are out of scope.
MPLS support for multipath techniques is considered essential by many
service providers and is useful for other high capacity networks. In
order to obtain sufficient entropy from MPLS traffic service
providers and others find it essential for the MPLS implementation to
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
protocol field, and UDP and TCP port number fields in multipath load
balancing are considered within scope. The use of any other IP
protocol fields, such as tunneling protocols carried within IP, are
out of scope.
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
all forwarding operations are implemented in specialized forwarding
hardware rather than on a special purpose processor. This is often
referred to as "fast path" and "slow path" processing. Some
recommendations are made regarding implemeting control or management
plane functionality in specialized hardware or with limited
assistance from specialized hardware. This advise is based on
expected control or management protocol loads and on the need for
denial of service (DoS) protection.
1.1. Acronyms
The following acronyms are used.
AC Attachment Circuit ([RFC3985])
ACH Associated Channel Header (pseudowires)
ACK Acknowledgement (TCP flag and type of packet)
AIS Alarm Indication Signal (MPLS-TP OAM)
ATM Asynchronous Transfer Mode (legacy switched circuits)
BFD Bidirectional Forwarding Detection
BGP Border Gateway Protocol
CC-CV Connectivity Check and Connectivity Verification
CE Customer Edge (LDP)
CPU Central Processing Unit (computer or microprocessor)
CT Class Type ([RFC4124])
CW Control Word ([RFC4385])
DCCP Datagram Congestion Control Protocol
DDoS Distributed Denial of Service
DM Delay Measurement (MPLS-TP OAM)
DSCP Differentiated Services Code Point ([RFC2474])
DWDM Dense Wave Division Multiplexing
DoS Denial of Service
E-LSP EXP-Inferred-PSC LSP ([RFC3270])
EBGP External BGP
ECMP Equal Cost Multi-Path
ECN Explicit Congestion Notification ([RFC3168] and [RFC5129])
EL Entropy Label ([RFC6790])
ELI Entropy Label Indicator ([RFC6790])
EXP Experimental (field in MPLS renamed to TC in [RFC5462])
FEC Forwarding Equivalence Classes (LDP), also Forward Error
Correction in other context
FR Frame Relay (legacy switched circuits)
FRR Fast Reroute ([RFC4090])
G-ACh Generic Associated Channel ([RFC5586])
GAL Generic Associated Channel Label ([RFC5586])
GFP Generic Framing Protocol (used in OTN)
GMPLS Generalized MPLS ([RFC3471])
GTSM Generalized TTL Security Mechanism ([RFC5082])
Gb/s Gigabits per second (billion bits per second)
IANA Internet Assigned Numbers Authority
ILM Incoming Label Map ([RFC3031])
IP Internet Protocol
IPVPN Internet Protocol VPN
IPv4 Internet Protocol version 4
IPv6 Internet Protocol version 6
L-LSP Label-Only-Inferred-PSC LSP ([RFC3270])
L2VPN Layer 2 VPN
LDP Label Distribution Protocol ([RFC5036])
LER Label Edge Router ([RFC3031])
LM Loss Measurement (MPLS-TP OAM)
LSP Label Switched Path ([RFC3031])
LSR Label Switching Router ([RFC3031])
MP2MP Multipoint to Point
MPLS MultiProtocol Label Switching ([RFC3031])
MPLS-TP MPLS Transport Profile ([RFC5317])
Mb/s Megabits per second (million bits per second)
NSP Native Service Processing ([RFC3985])
NTP Network Time Protocol
OAM Operations, Administration, and Maintenance ([RFC6291])
OOB Out-of-band (not carried within a data channel)
OTN Optical Transport Network
P Provider router (LDP)
P2MP Point to Multi-Point
PE Provider Edge router (LDP)
PHB Per-Hop-Behavior ([RFC2475])
PHP Penultimate Hop Popping ([RFC3443])
POS Packet over SONET
PSC This acronym has multiple interpretations.
1. Packet Switch Capable ([RFC3471]
2. PHB Scheduling Class ([RFC3270])
3. Protection State Coordination (MPLS-TP linear protection)
PTP Precision Time Protocol
PW Pseudowire
QoS Quality of Service
RA Router Alert ([RFC3032])
RDI Remote Defect Indication (MPLS-TP OAM)
RSVP-TE RSVP Traffic Engineering
RTP Real-Time Transport Protocol
SCTP Stream Control Transmission Protocol
SDH Synchronous Data Hierarchy (European SONET, a form of TDM)
SONET Synchronous Optical Network (US SDH, a form of TDM)
T-LDP Targeted LDP (LDP sessions over more than one hop)
TC Traffic Class ([RFC5462])
TCP Transmission Control Protocol
TDM Time-Division Multiplexing (legacy encapsulations)
TOS Type of Service (see [RFC2474])
TTL Time-to-live (a field in IP and MPLS headers)
UDP User Datagram Protocol
UHP Ultimate Hop Popping (opposite of PHP)
VCCV Virtual Circuit Connectivity Verification ([RFC5085])
VLAN Virtual Local Area Network (Ethernet)
VOQ Virtual Output Queuing (switch fabric design)
VPN Virtual Private Network
WG Working Group
1.2. Use of Requirements Language
This document is informational. The key words "MUST", "MUST NOT", This document is informational. The key words "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"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, implementators may be doing so at their own peril.
1.2. 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 RFC 3031
[RFC3031] states "The label stack mechanism allows LSP tunneling [RFC3031] states "The label stack mechanism allows LSP tunneling
to nest to any depth." If a the bottom of the label stack cannot to nest to any depth." If a bottom of the label stack cannot be
be found, but sufficient number of labels exist to forward, an found, but sufficient number of labels exist to forward, an LSR
LSR MUST forward the packet. An LSR MUST NOT assume the packet MUST forward the packet. An LSR MUST NOT assume the packet is
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].
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.
skipping to change at page 5, line 24 skipping to change at page 9, line 49
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 implementor and system designer MUST support pseudowire
control word if MPLS-TP is supported or if ACH is being used on a control word if MPLS-TP is supported or if ACH is being used on a
pseudowire [RFC5586]. Deployments SHOULD enable pseudowire pseudowire [RFC5586]. The implementor and system designer SHOULD
control word. See Section 2.4.1. support pseudowire control word if MPLS-TP and [RFC5586] are not
used [RFC5085]. Deployments SHOULD enable pseudowire control
word. See Section 2.4.1.
6. The implementor and system designer SHOULD support adding a 6. The implementor 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 a MPLS 7. The implementor 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.3. Target Audience 1.4. Target Audience
This document is intended for multiple audiences: implementor This document is intended for multiple audiences: implementor
(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: implementor)
skipping to change at page 6, line 24 skipping to change at page 10, line 50
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
Section 4. Section 4.
2.1. Forwarding Basics 2.1. Forwarding Basics
Basic MPLS architecture and MPLS encapsulation, and therefore packet Basic MPLS architecture and MPLS encapsulation, and therefore packet
forwarding is defined in [RFC3031] and [RFC3032]. RFC3031 and forwarding are defined in [RFC3031] and [RFC3032]. RFC3031 and
RFC3032 are somewhat LDP centric. RSVP-TE supports traffic RFC3032 are somewhat LDP centric. RSVP-TE supports traffic
engineering (TE) and fast reroute, features that LDP lacks. The base engineering (TE) and fast reroute, features that LDP lacks. The base
document for RSVP-TE based MPLS is [RFC3209]. document for RSVP-TE based MPLS is [RFC3209].
A few RFCs update RFC3032. Those with impact on forwarding include A few RFCs update RFC3032. Those with impact on forwarding include
the following. the following.
1. TTL processing is clarified in [RFC3443]. 1. TTL processing is clarified in [RFC3443].
2. The use of MPLS Explicit NULL is modified in [RFC4182]. 2. The use of MPLS Explicit NULL is modified in [RFC4182].
skipping to change at page 7, line 5 skipping to change at page 11, line 30
4. ECN is supported by [RFC5129]. 4. ECN is supported by [RFC5129].
5. The MPLS G-ACh and GAL are defined in [RFC5586]. 5. The MPLS G-ACh and GAL are defined in [RFC5586].
Other RFCs have implications to MPLS Forwarding and do not update Other RFCs have implications to MPLS Forwarding and do not update
RFC3032 or RFC3209, including: RFC3032 or RFC3209, including:
1. The pseudowire (PW) Associated Channel Header (ACH), defined by 1. The pseudowire (PW) Associated Channel Header (ACH), defined by
[RFC5085], later generalized by the MPLS G-ACh [RFC5586]. [RFC5085], later generalized by the MPLS G-ACh [RFC5586].
2. The Entropy Label Indicator and Entropy Label are defined by 2. The entropy label indicator (ELI) and entropy label (EL) are
[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 Reserved Labels
[RFC3032] specifies that label values 0-15 are reserved labels with [RFC3032] specifies that label values 0-15 are reserved labels with
special meanings. Three values of NULL label are defined (two of special meanings. Three values of NULL label are defined (two of
which are later updated by [RFC4182]) and a router-alert label is 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 reserved labels, except the
NULL labels, could be sent to the routing engine CPU rather than be NULL labels, could be sent to the routing engine CPU rather than be
processed in forwarding hardware. Hardware support is required by 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 reserved 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. For example, ELI will only be sent to LSR which general purpose CPU or other highly programmable hardware. For
have signaled support for [RFC6790] and high OAM packet rate must be example, ELI will only be sent to LSR which have signaled support for
negotiated among endpoints. [RFC6790] and high OAM packet rate must be negotiated among
endpoints.
[RFC3429] reserves a label for ITU-T Y.1711, however Y.1711 does not [RFC3429] reserves a label for ITU-T Y.1711, however Y.1711 does not
work with multipath and its use is strongly discouraged. work with multipath and its use is strongly discouraged.
The current list of reserved labels can be found on the The current list of reserved 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 When an unknown reserved label is encountered or a reserved label not
directly handled in forwarding hardware is encountered, the packet directly handled in forwarding hardware is encountered, the packet
skipping to change at page 8, line 8 skipping to change at page 12, line 35
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.
MPLS uses the Traffic Class (TC) field to support Differentiated MPLS uses the Traffic Class (TC) field to support Differentiated
Services [RFC5462]. There are two primary documents describing how Services [RFC5462]. There are two primary documents describing how
DSCP is mapped into TC. DSCP is mapped into TC.
1. [RFC3270] defines E-LSP and L-LSP. E-LSP use a static mapping of 1. [RFC3270] defines E-LSP and L-LSP. E-LSP use a static mapping of
DSCP into TC. L-LSP use a per LSP mapping of DSCP into TC, with DSCP into TC. L-LSP uses a per LSP mapping of DSCP into TC, with
one PHB Scheduling Class (PSC) per L-LSP. Each PSC can use one PHB Scheduling Class (PSC) per L-LSP. Each PSC can use
multiple Per-Hop Behavior (PHB) values. For example, the Assured multiple Per-Hop Behavior (PHB) values. For example, the Assured
Forwarding service defines three PSC, each with three PHB Forwarding service defines three PSC, each with three PHB
[RFC2597]. [RFC2597].
2. [RFC4124] defines assignment of a class-type (CT) to an LSP, 2. [RFC4124] defines assignment of a class-type (CT) to an LSP,
where a per CT static mapping of TC to PHB is used. [RFC4124] where a per CT static mapping of TC to PHB is used. [RFC4124]
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.
skipping to change at page 8, line 32 skipping to change at page 13, line 11
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.
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. outgoing packets. PTP correction which occurs when forwarding
requires updating a timestamp compensation field based on the
difference between packet arrival at an LSR and packet transmit time
at that same LSR.
Since the label stack depth may vary, hardware should allow a Since the label stack depth may vary, hardware should allow a
timestamp to be placed in an outgoing packet at any specified byte timestamp to be placed in an outgoing packet at any specified byte
position. It may be necessary to modify layer-2 checksums or frame position. It may be necessary to modify layer-2 checksums or frame
check sequences after insertion. PTP and NTP timestamp formats check sequences after insertion. PTP and NTP timestamp formats
differ slightly. differ slightly. If NTP or PTP is carried over UDP/IP or UDP/IP/
MPLS, the UDP checksum will also have to be updated.
Accurate time synchronization in addition to being generally useful Accurate time synchronization in addition to being generally useful
is required for MPLS-TP delay measurement (DM) OAM. See is required for MPLS-TP delay measurement (DM) OAM. See
Section 2.6.4. Section 2.6.4.
2.1.4. Uses of Multiple Label Stack Entries 2.1.4. Uses of Multiple Label Stack Entries
MPLS deployments in the early part of the prior decade (circa 2000) MPLS deployments in the early part of the prior decade (circa 2000)
tended to support either LDP or RSVP-TE. LDP was favored by some for tended to support either LDP or RSVP-TE. LDP was favored by some for
its ability to scale to a very large number of PE devices at the edge its ability to scale to a very large number of PE devices at the edge
skipping to change at page 9, line 14 skipping to change at page 13, line 45
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 PE's, 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] added one more label to MPLS traffic, The use of MPLS FRR [RFC4090] might add one more label to MPLS
but only when FRR protection was in use. If LDP over RSVP-TE is in traffic, but only when FRR protection was in use. If LDP over
use, and FRR protection is in use, then at least three MPLS labels RSVP-TE is in use, and FRR protection is in use, then at least three
are present on the label stack on the links through which the Bypass MPLS labels are present on the label stack on the links through which
LSP traverses. FRR is covered in Section 2.1.7. 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.
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
skipping to change at page 10, line 16 skipping to change at page 14, line 44
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 the "One-to-One Backup" method which uses the "Detour
LSP" and the " Facility Backup" which uses a "bypass tunnel". These LSP" and the " Facility Backup" which uses a "bypass tunnel". These
are commonly referred to as the detour and bypass methods are commonly referred to as the detour and bypass methods
respectively. 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 egress LSR of the bypass LSP MUST use
platform label space (as defined in [RFC3031]) so that an LSP working platform label space (as defined in [RFC3031]) so that an LSP working
path on any give interface can be backed up using a bypass LSP path on any give interface can be backed up using a bypass LSP
terminating on any other interface. Hardware assistance is needed if terminating on any other interface. Hardware assistance is needed if
necessary to accomplish local repair of a large number of LSP within necessary to accomplish local repair of a large number of LSP within
the 10s of milliseconds target. For each affected LSP a SWAP the 10s of milliseconds target. For each affected LSP a swap
operation must be reprogrammed or otherwise switched over with an operation must be reprogrammed or otherwise switched over with an
additional PUSH of the bypass LSP label. In addition the use of additional push of the bypass LSP label. In addition the use of
platform label space impacts the size of the LSR ILM for LSR with a platform label space impacts the size of the LSR ILM for LSR with a
very large number of interfaces. very large 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.
There are numerous pseudowire encapsulations, supporting emulation of There are numerous pseudowire encapsulations, supporting emulation of
services such as Frame Relay, ATM, Ethernet, TDM, and SONET/SDH over services such as Frame Relay, ATM, Ethernet, TDM, and SONET/SDH over
packet switched networks (PSNs) using IP or MPLS. packet switched networks (PSNs) using IP or MPLS.
The pseudowire encapsulation is out of scope for this document. The pseudowire encapsulation is out of scope for this document.
Pseudowire impact on MPLS forwarding at midpoint LSR is within scope. Pseudowire impact on MPLS forwarding at midpoint LSR is within scope.
The impact on ingress MPLS PUSH and egress MPLS UHP POP are within The impact on ingress MPLS push and egress MPLS UHP pop are within
scope. While pseudowire encapsulation is out of scope, some advice scope. While pseudowire encapsulation is out of scope, some advice
is given on sequence number support. is given on sequence number support.
2.1.8.1. Pseudowire Sequence Number 2.1.8.1. Pseudowire Sequence Number
Pseudowire (PW) sequence number support is most important for PW Pseudowire (PW) sequence number support is most important for PW
payload types with a high expectation of in-order delivery. payload types with a high expectation of in-order delivery.
Resequencing support, rather than dropping at egress on out of order Resequencing support, rather than dropping at egress on out of order
arrival, is most important for PW payload types with a high arrival, is most important for PW payload types with a high
expectation of lossless delivery. For example, TDM payloads require expectation of lossless delivery. For example, TDM payloads require
skipping to change at page 12, line 12 skipping to change at page 16, line 38
disable periodic hash reseeding and deployments should disable disable periodic hash reseeding and deployments should disable
periodic hash reseeding. periodic hash reseeding.
2.1.9. Layer-2 and Layer-3 VPN 2.1.9. Layer-2 and Layer-3 VPN
Layer-2 VPN [RFC4664] and Layer-3 VPN [RFC4110] add one or more label Layer-2 VPN [RFC4664] and Layer-3 VPN [RFC4110] add one or more label
entry to the MPLS label stack. VPN encapsulations are out of scope entry to the MPLS label stack. VPN encapsulations are out of scope
for this document. Its impact on forwarding at midpoint LSR are for this document. Its impact on forwarding at midpoint LSR are
within scope. within scope.
Any of these services may be used on an MPLS Entropy Label enabled Any of these services may be used on an MPLS entropy label enabled
ingress and egress (see Section 2.4.4 for discussion of Entropy ingress and egress (see Section 2.4.4 for discussion of entropy
Label) which would add an additional label to the MPLS label stack. label) which would add an additional label to the MPLS label stack.
The need to provide a useful Entropy Label value impacts the The need to provide a useful entropy label value impacts the
requirements of the VPN ingress LER but is out of scope for this requirements of the VPN ingress LER but is out of scope for this
document. document.
2.2. MPLS Multicast 2.2. MPLS Multicast
MPLS Multicast encapsulation is clarified in [RFC5332]. MPLS MPLS Multicast encapsulation is clarified in [RFC5332]. MPLS
Multicast may be signaled using RSVP-TE [RFC4875] or LDP [RFC6388]. Multicast may be signaled using RSVP-TE [RFC4875] or LDP [RFC6388].
[RFC4875] defines a root initiated RSVP-TE LSP setup rather than leaf [RFC4875] defines a root initiated RSVP-TE LSP setup rather than leaf
initiated join used in IP multicast. [RFC6388] defines a leaf initiated join used in IP multicast. [RFC6388] defines a leaf
initiated LDP setup. Both [RFC4875] and [RFC6388] define point to initiated LDP setup. Both [RFC4875] and [RFC6388] define point to
multipoint (P2MP) LSP setup. [RFC6388] also defined multipoint to multipoint (P2MP) LSP setup. [RFC6388] also defined multipoint to
multipoint (MP2MP) LSP setup. multipoint (MP2MP) LSP setup.
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 is performed. The bud requires that intermediate node a MPLS swap operation is performed. The bud
both a POP and SWAP be performed for the same incoming packet. requires that both a pop operation and a swap operation be performed
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 ingress and then optionally push labels at each LSR egress. A given
LSR egress chip may support multiple egress interfaces, each of which LSR egress chip may support multiple egress interfaces, each of which
requires a copy, but each with a different set of added labels and requires a copy, but each with a different set of added labels and
layer-2 encapsulation. Some physical interfaces may have multiple layer-2 encapsulation. Some physical interfaces may have multiple
sub-interfaces (such as Ethernet VLAN or channelized interfaces) each sub-interfaces (such as Ethernet VLAN or channelized interfaces) each
requiring a copy. 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
skipping to change at page 14, line 9 skipping to change at page 18, line 38
Internet service providers and content providers generally specify Internet service providers and content providers generally specify
full rate forwarding with 40 byte payload packets as a requirement. full rate forwarding with 40 byte payload packets as a requirement.
This requirement often can be waived if the provider can be convinced This requirement often can be waived if the provider can be convinced
that when long sequence of short packets occur no packets will be that when long sequence of short packets occur no packets will be
dropped. 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 are 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
skipping to change at page 15, line 21 skipping to change at page 19, line 51
In order to support an adequately balanced load distribution across In order to support an adequately balanced load distribution across
multiple links, IP header information must be used. Common practice multiple links, IP header information must be used. Common practice
today is to reinspect the IP headers at each LSR and use the label today is to reinspect the IP headers at each LSR and use the label
stack and IP header information in a hash performed at each LSR. stack and IP header information in a hash performed at each LSR.
Further details are provided in Section 2.4.5. Further details are provided in Section 2.4.5.
The use of this technique is so ubiquitous in provider networks that The use of this technique is so ubiquitous in provider networks that
lack of support for multipath makes any product unsuitable for use in lack of support for multipath makes any product unsuitable for use in
large core networks. This will continue to be the case in the near large core networks. This will continue to be the case in the near
future, even as deployment of MPLS Entropy Label begins to relax the future, even as deployment of MPLS entropy label begins to relax the
core LSR multipath performance requirements given the existing core LSR multipath performance requirements given the existing
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 use Common practice today is to reinspect the packet at each LSR and
the label stack and use the IP header field as input to a hash information from the packet combined with a hash seed that is
algorithm performed on each packet at each LSR in the network selected by each LSR. Where flow labels or entropy labels are used,
combined with a hash seed that is selected by each LSR. Where flow a hash seed must be used when creating these labels.
labels or entropy labels are used, a hash seed must be used.
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.
A pseudowire encapsulated at a network edge must have a means to A pseudowire encapsulated at a network edge must have a means to
prevent reordering within the core if the pseudowire will be crossing prevent reordering within the core if the pseudowire will be crossing
skipping to change at page 16, line 49 skipping to change at page 21, line 29
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).
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 in the network core. Prior to the MPLS entropy label core 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 within the network core.
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.
2.4.5. Fields Used for Multipath 2.4.5. Fields Used for Multipath
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 are 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 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 below 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. Reserved labels (label values 0-15) MUST NOT be used. In
particular, GAL and RA MUST NOT be used so that OAM traffic particular, GAL and RA MUST NOT be used so that OAM traffic
follows the same path as payload packets with the same label follows the same path as payload packets with the same label
stack. stack.
skipping to change at page 18, line 24 skipping to change at page 23, line 4
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
and use appropriate fields from the IP headers. This feature is and use appropriate fields from the IP headers. This feature is
considered a hard requirement by many service providers. If considered a hard requirement by many service providers. If
supported, there MUST be a way to disable it (if, for example, PW supported, there MUST be a way to disable it (if, for example, PW
without CW are used). This ability to disable this feature is without CW are used). This ability to disable this feature is
considered a hard requirement by many service providers. considered a hard requirement by many service providers.
Therefore an implementation has a very strong incentive to Therefore an implementation has a very strong incentive to
support both options. support both options.
6. A label which is popped at egress (UHP POP) SHOULD NOT be used. 6. A label which is popped at egress (UHP pop) SHOULD NOT be used.
A label which is popped at the penultimate hop (PHP POP) SHOULD A label which is popped at the penultimate hop (PHP pop) SHOULD
be used. be used.
Apparently some chips have made use of the TC (formerly EXP) bits as Apparently some chips have made use of the TC (formerly EXP) bits as
a source of entropy. This is very harmful since it will reorder a source of entropy. This is very harmful since it will reorder
Assured Forwarding (AF) traffic [RFC2597] when a subset does not Assured Forwarding (AF) traffic [RFC2597] when a subset does not
conform to the configured rates and is remarked but not dropped at a conform to the configured rates and is remarked but not dropped at a
prior LSR. Traffic which uses MPLS ECN [RFC5129] can also be prior LSR. Traffic which uses MPLS ECN [RFC5129] can also be
reordered if TC is used for entropy. Therefore, as stated in the reordered if TC is used for entropy. Therefore, as stated in the
guidelines above, the TC field (formerly EXP) MUST NOT be used in guidelines above, the TC field (formerly EXP) MUST NOT be used in
multipath load balancing as it violates Differentiated Services multipath load balancing as it violates Differentiated Services
Ordered Aggregate (OA) requirements in these two instances. Ordered Aggregate (OA) requirements in these two instances.
Use of the MPLS label entry S bit would result in putting OAM traffic Use of the MPLS label entry S bit would result in putting OAM traffic
on a different path if the addition of a GAL at the bottom of stack on a different path if the addition of a GAL at the bottom of stack
removed the S bit from the prior label. removed the S bit from the prior label.
If an ELI label is found, then if the LSR supports Entropy Label, the If an ELI label is found, then if the LSR supports entropy label, the
EL label field in the next label entry (the EL) SHOULD be used and EL label field in the next label entry (the EL) SHOULD be used and
the search for additional entropy within the packet SHOULD be the search for additional entropy within the packet SHOULD be
terminated. Failure to terminate the search will impact client terminated. Failure to terminate the search will impact client
MPLS-TP LSP carried within server MPLS LSP. A network operator has MPLS-TP LSP carried within server MPLS LSP. A network operator has
the option to use administrative attributes as a means to identify the option to use administrative attributes as a means to identify
LSR which do not terminate the entropy search at the first EL. LSR which do not terminate the entropy search at the first EL.
Administrative attributes are defined in [RFC3209]. Some Administrative attributes are defined in [RFC3209]. Some
configuration is required to support this. configuration is required to support this.
If the PHP POP label is not used, then for any PW for which CW is If the label removed by a PHP pop is not used, then for any PW for
used, there is no basis for multipath load split. In some networks which CW is used, there is no basis for multipath load split. In
it is infeasible to put all PW traffic on one component link. Any PW some networks it is infeasible to put all PW traffic on one component
which does not use CW will be improperly split regardless of whether link. Any PW which does not use CW will be improperly split
the PHP POP label is used. regardless of whether the label removed by a PHP pop is used.
Therefore the PHP pop label SHOULD be used as recommended above.
2.4.5.2. IP Fields in Multipath 2.4.5.2. IP Fields in Multipath
Inspecting the IP payload provides the most entropy in provider Inspecting the IP payload provides the most entropy in provider
networks. The practice of looking past the bottom of stack label for networks. The practice of looking past the bottom of stack label for
an IP payload is well accepted and documented in [RFC4928] and in an IP payload is well accepted and documented in [RFC4928] and in
other RFCs. other RFCs.
Where IP is mentioned in the document, both IPv4 and IPv6 apply. All Where IP is mentioned in the document, both IPv4 and IPv6 apply. All
LSRs MUST fully support IPv6. LSRs MUST fully support IPv6.
When information in the IP header is used, the following guidelines When information in the IP header is used, the following guidelines
apply: apply:
1. Both the IP source address and IP destination address SHOULD be 1. Both the IP source address and IP destination address SHOULD be
used. There MAY be an option to reverse the order of these used. There MAY be an option to reverse the order of these
address, improving the ability to provide symmetric paths in some addresses, improving the ability to provide symmetric paths in
cases. Many service providers require that both addresses be some cases. Many service providers require that both addresses
used. be used.
2. Implementations SHOULD allow inspection of the IP protocol field 2. Implementations SHOULD allow inspection of the IP protocol field
and use of the UDP or TCP port numbers. For many service and use of the UDP or TCP port numbers. For many service
providers this feature is considered manditory, particularly for providers this feature is considered mandatory, particularly for
enterprise, data center, or edge equipment. If this feature is enterprise, data center, or edge equipment. If this feature is
provided, it SHOULD be possible to disable use of TCP and UDP provided, it SHOULD be possible to disable use of TCP and UDP
ports. Many service providers consider it a hard requirement ports. Many service providers consider it a hard requirement
that use of UDP and TCP ports can be disabled. Therefore there that use of UDP and TCP ports can be disabled. Therefore there
is a stong incentive for implementations to provide both options. is a stong incentive for implementations to provide both options.
3. Equipment suppliers MUST NOT make assumptions that because the IP 3. Equipment suppliers MUST NOT make assumptions that because the IP
version field is equal to 4 (an IPv4 packet) that the IP protocol version field is equal to 4 (an IPv4 packet) that the IP protocol
will either be TCP (IP protocol 6) or UDP (IP protocol 17) and will either be TCP (IP protocol 6) or UDP (IP protocol 17) and
blindly fetch the data at the offset where the TCP or UDP ports blindly fetch the data at the offset where the TCP or UDP ports
would be found. With IPv6, TCP and UDP port numbers are not at would be found. With IPv6, TCP and UDP port numbers are not at
fixed offsets. With IPv4 packets carrying IP options, TCP and fixed offsets. With IPv4 packets carrying IP options, TCP and
UDP port numbers are not at fixed offsets. UDP port numbers are not at fixed offsets.
4. The IPv6 header flow field SHOULD be used. This is the explicit 4. The IPv6 header flow field SHOULD be used. This is the explicit
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 af 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 absense 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 other protocols that share a common Layer-4 header such
as RTP, UDP-lite, SCTP and DCCP SHOULD be provided, particularly as RTP, UDP-lite, SCTP and DCCP SHOULD be provided, particularly
for edge or access equipment where additional entropy may be for edge or access equipment where additional entropy may be
needed. Equipment SHOULD also use RTP, UDP-lite, SCTP and DCCP needed. Equipment SHOULD also use RTP, UDP-lite, SCTP and DCCP
headers when creating an Entropy Label. headers when creating an entropy label.
6. Similar to avoiding TC in MPLS, the IP DSCP, and ECN bits MUST 6. The following IP header fields should not or must not be used:
NOT be used. The IPv4 TTL or IPv6 Hop Count SHOULD NOT be used.
Note that the IP TOS field was deprecated ([RFC0791] was updated A. Similar to avoiding TC in MPLS, the IP DSCP, and ECN bits
by [RFC2474]). No part of the IP DSCP (formerly IP PREC and IP MUST NOT be used.
TOS bits) field can 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
updated by [RFC2474]). No part of the IP DSCP field can be
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 therefoer implementors are free to ignore them, but due to RFC therefore implementors are free to ignore them, but due to
service provider requirements may be doing so at their own peril. service provider requirements may be doing so at their own peril.
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 21, line 30 skipping to change at page 26, line 17
applicable to generation of an entropy label at edge or access where applicable to generation of an entropy label at edge or access where
deep packet inspection is practical due to lower interface speeds deep packet inspection is practical due to lower interface speeds
than in the core where deep packet inspection may be impractical. than in the core where deep packet inspection may be impractical.
2.5. MPLS-TP and UHP 2.5. MPLS-TP and UHP
MPLS-TP introduces forwarding demands that will be extremely MPLS-TP introduces forwarding demands that will be extremely
difficult to meet in a core network. Most troublesome is the difficult to meet in a core network. Most troublesome is the
requirement for Ultimate Hop Popping (UHP, the opposite of requirement for Ultimate Hop Popping (UHP, the opposite of
Penultimate Hop Popping or PHP). Using UHP opens the possibility of Penultimate Hop Popping or PHP). Using UHP opens the possibility of
one or more MPLS POP operation plus an MPLS SWAP operation for each one or more MPLS pop operation plus an MPLS swap operation for each
packet. The potential for multiple lookups and multiple counter packet. The potential for multiple lookups and multiple counter
instances per packet exists. instances per packet exists.
As networks grow and tunneling of LDP LSPs into RSVP-TE LSPs is used, As networks grow and tunneling of LDP LSPs into RSVP-TE LSPs is used,
and/or RSVP-TE hierarchy is used, the requirement to perform one or and/or RSVP-TE hierarchy is used, the requirement to perform one or
two or more MPLS POP operations plus a MPLS SWAP operation (and two or more MPLS pop operations plus a MPLS swap operation (and
possibly a PUSH or two) increases. If MPLS-TP LM (link monitoring) possibly a push or two) increases. If MPLS-TP LM (link monitoring)
OAM is enabled at each layer, then a packet and byte count MUST be OAM is enabled at each layer, then a packet and byte count MUST be
maintained for each POP and SWAP operation so as to offer OAM for maintained for each pop and swap operation so as to offer OAM for
each layer. each layer.
2.6. OAM and DoS Protection 2.6. Local Delivery of Packets
There are a number of situations in which packets are destined to a
local address or where a return packet must be generated. There is a
need to mitigate the potential for outage as a result of either
attacks on network infrastructure, or in some cases unintentional
misconfiguration resulting in processor overload. Some hardware
assistance is needed for all traffic destined to the general purpose
CPU that is used in MPLS control protocol processing or network
management protocol processing and in most cases to other general
purpose CPUs residing on an LSR. This is due to the ease of
overwhelming such a processor with traffic arriving on LSR high speed
interfaces, whether the traffic is malicious or not.
Denial of service (DoS) protection is an area requiring hardware Denial of service (DoS) protection is an area requiring hardware
support that is often overlooked or inadequately considered. support that is often overlooked or inadequately considered.
Hardware assist is also needed for OAM, particularly the more Hardware assist is also needed for OAM, particularly the more
demanding MPLS-TP OAM. demanding MPLS-TP OAM.
2.6.1. DoS Protection 2.6.1. DoS Protection
Modern equipment supports a number of control plane and management Modern equipment supports a number of control plane and management
plane protocols. Generally no single means of protecting network plane protocols. Generally no single means of protecting network
skipping to change at page 22, line 16 skipping to change at page 27, line 16
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 along, the isolation from potentially malicious payload. Used alone, the
compromise of a single node, including a small computer at a compromise of a single node, including a small computer at a
network operations center, could compromise an entire network. network operations center, could compromise an entire network.
Implementations which send all G-ACh/GAL traffic directly to a Implementations which send all G-ACh/GAL traffic directly to a
routing engine CPU are subject to DoS attack as a result of such routing engine CPU are subject to DoS attack as a result of such
a compromise. a compromise.
Cryptographic Authentication Cryptographic Authentication
Cryptographic authentication can very effectively prevent Cryptographic authentication can very effectively prevent
malicious injection of control or management traffic. malicious injection of control or management traffic.
Cryptographic authentication can is some circumstances be subject Cryptographic authentication can is some circumstances be subject
to DoS attack by overwhelming the capacity of the decryption with to DoS attack by overwhelming the capacity of the decryption with
a high volume of malicious traffic. For very low speed a high volume of malicious traffic. For very low speed
interfaces cryptographic authentication can be performed by the interfaces, cryptographic authentication can be performed by the
general purpose CPU used as a routing engine. For all other general purpose CPU used as a routing engine. For all other
cases, cryptographic hardware may be needed. For very high speed cases, cryptographic hardware may be needed. For very high speed
interfaces, even cryptographic hardware can be overwhelmed. interfaces, even cryptographic hardware can be overwhelmed.
Some control and management protocols are often carried with payload Some control and management protocols are often carried with payload
traffic. This is commonly the case with BGP, T-LDP, and SNMP. It is traffic. This is commonly the case with BGP, T-LDP, and SNMP. It is
often the case with RSVP-TE. Even when carried over G-ACh/GAL often the case with RSVP-TE. Even when carried over G-ACh/GAL
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.
skipping to change at page 23, line 42 skipping to change at page 28, line 42
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 migh make use of overhead bits in SONET or OTN or a dedicated
DWDM wavelength. G-ACh and GAL provide an alternative OOB mechanism DWDM wavelength. G-ACh and GAL provide an alternative OOB mechanism
which is independent of underlying layers. In other networks, which is independent of underlying layers. In other networks,
including most IP/MPLS networks, perimeter filtering serves a similar including most IP/MPLS networks, perimeter filtering serves a similar
purpose, though less effective without extreme vigalence. 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 24, line 30 skipping to change at page 29, line 30
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 against the
control plane, where LSP Ping does. LSP Ping somewhat better suited control plane, where LSP Ping does. LSP Ping somewhat better suited
for on-demand monitoring including relatively low rate periodic for on-demand monitoring including relatively low rate periodic
verification of data plane and as a diagnostic tool. verification of data plane and as a diagnostic tool.
Both BFD and LSP Ping MUST be recognized by hardware and at the very Hardware assistance is often provided for BFD response where BFD
minimum forwarded to the main CPU. Hardware assistance for BFD is setup or parameter change is not involved and may be necessary for
often provided and is considered necessary for relatively high rate relatively high rate proactive monitoring. If both BFD and LSP Ping
proactive monitoring. Both BFD and LSP Ping MUST be recognized in are recognized in filtering prior to passing traffic to a general
any filtering prior to passing traffic to a general purpose CPU and purpose CPU, appropriate DoS protection can be applied (see
appropriate DoS protection applied (see Section 2.6.1. Failure to Section 2.6.1). Failure to recognize BFD and LSP Ping and at least
recognize BFD and LSP Ping and at least rate limit creates the rate limit creates the potential for misconfiguration to cause
potential for misconfiguration to cause outages rather than cause outages rather than cause errors in the misconfigured OAM.
errors in the misconfigured OAM.
2.6.3. Pseudowire OAM 2.6.3. Pseudowire OAM
Pseudowire OAM makes use of the control channel provided by Virtual Pseudowire OAM makes use of the control channel provided by Virtual
Circuit Connectivity Verification (VCCV) [RFC5085]. VCCV makes use Circuit Connectivity Verification (VCCV) [RFC5085]. VCCV makes use
of the Pseudowire Control Word. BFD support over VCCV is defined by of the Pseudowire Control Word. BFD support over VCCV is defined by
[RFC5885]. [RFC5885] is updated by [RFC6478] in support of static [RFC5885]. [RFC5885] is updated by [RFC6478] in support of static
pseudowires. [RFC4379] is updated by [RFC6829] supporting LSP Ping pseudowires. [RFC4379] is updated by [RFC6829] supporting LSP Ping
for Pseudowire FEC advertised over IPv6. for Pseudowire FEC advertised over IPv6.
skipping to change at page 25, line 14 skipping to change at page 30, line 14
2.6.4. MPLS-TP OAM 2.6.4. MPLS-TP OAM
[RFC6669] summarizes the MPLS-TP OAM toolset, the set of protocols [RFC6669] summarizes the MPLS-TP OAM toolset, the set of protocols
supporting the MPLS-TP OAM requirements specified in [RFC5860] and supporting the MPLS-TP OAM requirements specified in [RFC5860] and
supported by the MPLS-TP OAM framework defined in [RFC6371]. supported by the MPLS-TP OAM framework defined in [RFC6371].
The MPLS-TP OAM toolset includes: The MPLS-TP OAM toolset includes:
CC-CV CC-CV
[RFC6428] defines BFD extensions to support proactive CC-CV [RFC6428] defines BFD extensions to support proactive
Connectivity Check and Connectivity Verification (CC-CV)
applications. [RFC6426] provides LSP ping extensions that are applications. [RFC6426] provides LSP ping extensions that are
used to implement on-demand connectivity verification. used to implement on-demand connectivity verification.
RDI RDI
Remote Defect Indication (RDI) is triggered by failure of Remote Defect Indication (RDI) is triggered by failure of
proactive CC-CV, which is BFD based. For fast RDI initiation, proactive CC-CV, which is BFD based. For fast RDI initiation,
RDI SHOULD be initiated and handled by hardware if BFD is handled RDI SHOULD be initiated and handled by hardware if BFD is handled
in forwarding hardware. [RFC6428] provides an extension for BFD in forwarding hardware. [RFC6428] provides an extension for BFD
that includes the RDI indication in the BFD format and a that includes the RDI indication in the BFD format and a
specification of how this indication is to be used. specification of how this indication is to be used.
Route Tracing Route Tracing
[RFC6426] specifies that the LSP ping enhancements for MPLS-TP [RFC6426] specifies that the LSP ping enhancements for MPLS-TP
on-demand connectivity verification include information on the on-demand connectivity verification include information on the
use of LSP ping for route tracing of an MPLS-TP path. use of LSP ping for route tracing of an MPLS-TP path.
Alarm Reporting Alarm Reporting
[RFC6427] describes the details of a new protocol supporting [RFC6427] describes the details of a new protocol supporting
Alarm Indication Signal, Link Down Indication, and fault Alarm Indication Signal (AIS), Link Down Indication, and fault
management. This functionality SHOULD be supported in forwarding management. Failure to support this functionality in forwarding
hardware on high speed interfaces. hardware can potentially result in failure to meet protection
recovery time requirements and is therefore strongly recommended.
Lock Instruct Lock Instruct
Lock instruct is initiated on-demand and therefore need not be Lock instruct is initiated on-demand and therefore need not be
implemented in forwarding hardware. [RFC6435] defines a lock implemented in forwarding hardware. [RFC6435] defines a lock
instruct protocol. instruct protocol.
Lock Reporting Lock Reporting
[RFC6427] covers lock reporting. Lock reporting need not be [RFC6427] covers lock reporting. Lock reporting need not be
implemented in forwarding hardware. implemented in forwarding hardware.
skipping to change at page 26, line 11 skipping to change at page 31, line 11
initiation is on-demand and therefore need not be implemented in initiation is on-demand and therefore need not be implemented in
forwarding hardware. Loopback of packet traffic SHOULD be forwarding hardware. Loopback of packet traffic SHOULD be
implemented in forwarding hardware on high speed interfaces. implemented in forwarding hardware on high speed interfaces.
Packet Loss and Delay Measurement Packet Loss and Delay Measurement
[RFC6374] and [RFC6375] define a protocol and profile for packet [RFC6374] and [RFC6375] define a protocol and profile for packet
loss measurement (LM) and delay measurement (DM). LM requires a loss measurement (LM) and delay measurement (DM). LM requires a
very accurate capture and insertion of packet and byte counters very accurate capture and insertion of packet and byte counters
when a packet is transmitted and capture of packet and byte when a packet is transmitted and capture of packet and byte
counters when a packet is received. This capture and insertion counters when a packet is received. This capture and insertion
MUST be implemented in forwarding hardware for LM OAM to be MUST be implemented in forwarding hardware for LM OAM if high
sufficiently accurate. DM requires very accurate capture and accuracy is needed. DM requires very accurate capture and
insertion of a timestamp on transmission and capture of timestamp insertion of a timestamp on transmission and capture of timestamp
when a packet is received. This timestamp capture and insertion when a packet is received. This timestamp capture and insertion
MUST be implemented in forwarding hardware for DM OAM to be MUST be implemented in forwarding hardware for DM OAM if high
sufficiently accurate. accuracy is needed.
See Section 2.6.2 for discussion of hardware support necessary for See Section 2.6.2 for discussion of hardware support necessary for
BFD and LSP Ping. BFD and LSP Ping.
CC-CV and alarm reporting is tied to protection and therefore SHOULD CC-CV and alarm reporting is tied to protection and therefore SHOULD
be supported in forwarding hardware in order to provide protection be supported in forwarding hardware in order to provide protection
for a large number of affected LSP within target response intervals. for a large number of affected LSP within target response intervals.
Since CC-CV is supported by BFD, for MPLS-TP, BFD SHOULD be supported Since CC-CV is supported by BFD, for MPLS-TP providing hardware
in forwarding hardware. assistance for BFD processing helps insure that protection recovery
time requirements can be met even for faults affecting a large number
of LSP.
2.6.5. MPLS OAM and Layer-2 OAM Interworking 2.6.5. MPLS OAM and Layer-2 OAM Interworking
[RFC6670] provides the reasons for selecting a single MPLS-TP OAM [RFC6670] provides the reasons for selecting a single MPLS-TP OAM
solution and examines the consequences were ITU-T to develop a second solution and examines the consequences were ITU-T to develop a second
OAM solution that is based on Ethernet encodings and mechanisms. OAM solution that is based on Ethernet encodings and mechanisms.
[RFC6310] and [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.
An MPLS OAM implementation SHOULD interwork with the underlying It is beneficial if an MPLS OAM implementation can interwork with the
server layer and provide a means to interwork with a client layer. underlying server layer and provide a means to interwork with a
Where MPLS hierarchy is used both the client and server layer may be client layer. For example, [RFC6427] specifies an inter-layer
MPLS or MPLS-TP. Where the server layer is a Layer-2, such as propogation of AIS and LDI from MPLS server layer to client MPLS
Ethernet, PPP over SONET/SDH, or GFP over OTN, interwork among layers layers. Where the server layer is a Layer-2, such as Ethernet, PPP
is also required. For high speed interfaces, this interworking over SONET/SDH, or GFP over OTN, interwork among layers is also
SHOULD be supported in forwarding hardware. beneficial. For high speed interfaces, supporting this interworking
in forwarding hardware helps insure that protection based on this
interworking can meet recovery time requirements even for faults
affecting a large number of LSP.
2.6.6. Extent of OAM Support by Hardware 2.6.6. Extent of OAM Support by Hardware
Some OAM functionality must be supported in forwarding hardware while Where certain requirements must be met, such as relatively high CC-CV
other OAM functionality must be entirely implemented in forwarding rates and a large number of interfaces, or strict protection recovery
hardware. time requirements and a moderate number of affected LSP, some OAM
functionality must be supported by forwarding hardware. In other
cases, such as highly accurate LM and DM OAM or strict protection
recovery time requirements with a large number of affected LSP, OAM
functionality must be entirely implemented in forwarding hardware.
Where possible, implementation in forwarding hardware should be in Where possible, implementation in forwarding hardware should be in
programmable hardware such that if standards are later changed or programmable hardware such that if standards are later changed or
extended these changes are likely to be accommodated with hardware extended these changes are likely to be accommodated with hardware
reprogramming rather than replacement. reprogramming rather than replacement.
Some functions must be implemented in dedicated forwarding hardware. For some functionality there is a strong case for an implementation
Examples include packet and byte counters needed for LM OAM as well in dedicated forwarding hardware. Examples include packet and byte
as needed for management protocols. Similarly the capture and counters needed for LM OAM as well as needed for management
insertion of packet and byte counts or timestamps needed for protocols. Similarly the capture and insertion of packet and byte
transmitted LM or DM or time synchronization packets MUST be counts or timestamps needed for transmitted LM or DM or time
implemented in forwarding hardware to support accurate OAM. synchronization packets MUST be implemented in forwarding hardware if
high accuracy is required.
Some functions must be supported in forwarding hardware but may make For some functions there is a strong case to provide limited support
use of an external general purpose processor if performance criteria in forwarding hardware but may make use of an external general
can be met. For example origination of AIS to client layers may be purpose processor if performance criteria can be met. For example
triggered by CC-CV server layer hardware but expansion to a large origination of RDI triggered by CC-CV, response to RDI, and PSC
number of client LSP may occur in a general purpose processor. Some functionality may be supported by hardware, but expansion to a large
forwarding hardware supports one or more on-chip general purpose number of client LSP and transmission of AIS or RDI to the client LSP
processors which may be well suited for such a role. may occur in a general purpose processor. Some forwarding hardware
supports one or more on-chip general purpose processors which may be
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 implementors 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
skipping to change at page 28, line 19 skipping to change at page 33, line 34
3. Questions for Suppliers 3. Questions for Suppliers
The following questions should be asked of a supplier. These The following questions should be asked of a supplier. These
questions are grouped into broad categories. The questions questions are grouped into broad categories. The questions
themselves are intended to be an open ended question to the supplier. themselves are intended to be an open ended question to the supplier.
The tests in Section 4 are intended to verify whether the supplier The tests in Section 4 are intended to verify whether the supplier
disclosed any compliance or performance limitations completely and disclosed any compliance or performance limitations completely and
accurately. accurately.
Basic Compliance 3.1. Basic Compliance
Q#1 Can the implementation forward packets with an arbitrarily Q#1 Can the implementation forward packets with an arbitrarily
large stack depth? What limitations exist, and under what large stack depth? What limitations exist, and under what
circumstances do further limitations come into play (such circumstances do further limitations come into play (such as
as high packet rate or specific features enabled or high packet rate or specific features enabled or specific types
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 Q#3 Are the set of MPLS reserved labels handled correctly and with
with adequate performance? See Section 2.1.1. adequate performance? See Section 2.1.1.
Q#4 Are mappings of label value and TC to PHB handled Q#4 Are mappings of label value and TC to PHB handled correctly,
correctly, including RFC3270 L-LSP mappings and RFC4124 CT including RFC3270 L-LSP mappings and RFC4124 CT mappings to
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?
b. Is the accuracy of timestamp insertion and incoming B. Is the accuracy of timestamp insertion and incoming
stamping sufficient? stamping sufficient?
See Section 2.1.3. See Section 2.1.3.
Q#6 Is link bundling supported? Q#6 Is link bundling supported?
a. Can LSP be pinned to specific components? A. Can LSP be pinned to specific components?
b. Is the "all-ones" component link supported?
See Section 2.1.5. B. Is the "all-ones" component link supported?
Q#7 Is MPLS hierarchy supported? See Section 2.1.5.
a. Are both PHP and UHP supported? What limitations exist Q#7 Is MPLS hierarchy supported?
on the number of POP operations with UHP?
b. Are the pipe, short-pipe, and uniform models supported? A. Are both PHP and UHP supported? What limitations exist on
Are TTL and TC values updated correctly at egress where the number of pop operations with UHP?
applicable?
See Section 2.1.6 B. Are the pipe, short-pipe, and uniform models supported?
Are TTL and TC values updated correctly at egress where
applicable?
Q#8 Are pseudowire sequence numbers handled correctly? See See Section 2.1.6
Section 2.1.8.1.
Q#9 Is VPN LER functionality handled correctly and without Q#8 Are pseudowire sequence numbers handled correctly? See
performance issues? See Section 2.1.9. Section 2.1.8.1.
Q#10 Is MPLS multicast (P2MP and MP2MP) handled correctly? Q#9 Is VPN LER functionality handled correctly and without
performance issues? See Section 2.1.9.
a. Are packets dropped on uncongested outputs if some Q#10 Is MPLS multicast (P2MP and MP2MP) handled correctly?
outputs are congested?
b. Is performance limited in high fanout situations? A. Are packets dropped on uncongested outputs if some outputs
are congested?
See Section 2.2. B. Is performance limited in high fanout situations?
Basic Performance See Section 2.2.
Q#11 Can very small packets be forwarded at full line rate on 3.2. Basic Performance
all interfaces indefinitely? What limitations exist, and
under what circumstances do further limitations come into
play (such as specific features enabled or specific types
of packet processing)?
Q#12 Customers must decide whether to relax the prior Q#11 Can very small packets be forwarded at full line rate on all
requirement and to what extent. If the answer to the prior interfaces indefinitely? What limitations exist, and under
question indicates that limitations exist, then: what circumstances do further limitations come into play (such
as specific features enabled or specific types of packet
processing)?
a. What is the smallest packet size where full line rate Q#12 Customers must decide whether to relax the prior requirement
forwarding can be supported? and to what extent. If the answer to the prior question
indicates that limitations exist, then:
b. What is the longest burst of full rate small packets A. What is the smallest packet size where full line rate
that can be supported? forwarding can be supported?
Specify circumstances (such as specific features enabled or B. What is the longest burst of full rate small packets that
specific types of packet processing) often impact these can be supported?
rates and burst sizes.
Q#13 How many POP operations can be supported along with a SWAP Specify circumstances (such as specific features enabled or
operation at full line rate while maintaining per LSP specific types of packet processing) often impact these rates
packet and byte counts for each POP and SWAP? This and burst sizes.
requirement is particularly relevant for MPLS-TP.
Q#14 How many PUSH labels can be supported. While this Q#13 How many pop operations can be supported along with a swap
limitation is rarely an issue, it applies to both PHP and operation at full line rate while maintaining per LSP packet
UHP, unlike the POP limit which applies to UHP. and byte counts for each pop and swap? This requirement is
particularly relevant for MPLS-TP.
Q#15 For a worst case where all packets arrive on one LSP, what Q#14 How many label push operations can be supported. While this
is the counter overflow time? Are any means provided to limitation is rarely an issue, it applies to both PHP and UHP,
avoid polling all counters at short intervals? This unlike the pop limit which applies to UHP.
applies to both MPLS and MPLS-TP.
Multipath Capabilities and Performance Q#15 For a worst case where all packets arrive on one LSP, what is
Multipath capabilities and performance do not apply to MPLS-TP the counter overflow time? Are any means provided to avoid
but apply to MPLS and apply if MPLS-TP is carried in MPLS. polling all counters at short intervals? This applies to both
MPLS and MPLS-TP.
Q#16 How are large microflows accommodated? Is there active 3.3. Multipath Capabilities and Performance
management of the hash space mapping to output ports? See
Section 2.4.2.
Q#17 How many MPLS labels can be included in a hash based on the Multipath capabilities and performance do not apply to MPLS-TP but
MPLS label stack? apply to MPLS and apply if MPLS-TP is carried in MPLS.
Q#18 Is packet rate performance decreased beyond some number of Q#16 How are large microflows accommodated? Is there active
labels? management of the hash space mapping to output ports? See
Section 2.4.2.
Q#19 Can the IP header and payload information below the MPLS Q#17 How many MPLS labels can be included in a hash based on the
stack be used in the hash? If so, which IP fields, payload MPLS label stack?
types and payload fields are supported?
Q#20 At what maximum MPLS label stack depth can Bottom of Stack Q#18 Is packet rate performance decreased beyond some number of
and an IP header appear without impacting packet rate labels?
performance?
Q#21 Are reserved labels excluded from the label stack hash? Q#19 Can the IP header and payload information below the MPLS stack
They MUST be excluded. be used in the hash? If so, which IP fields, payload types and
payload fields are supported?
Q#22 How is multipath performance affected by very large flows Q#20 At what maximum MPLS label stack depth can Bottom of Stack and
or an extremely large number of flows, or by very short an IP header appear without impacting packet rate performance?
lived flows? See Section 2.7.
Pseudowire Capabilities and Performance Q#21 Are reserved labels excluded from the label stack hash? See
Section 2.4.5.1.
Q#23 Is the pseudowire control word supported? Q#22 How is multipath performance affected by very large flows or an
extremely large number of flows, or by very short lived flows?
See Section 2.7.
Q#24 What is the maximum rate of pseudowire encapsulation and 3.4. Pseudowire Capabilities and Performance
decapsulation? Apply the same questions as in Base
Performance for any packet based pseudowire such as IP VPN
or Ethernet.
Q#25 Does inclusion of a pseudowire control word impact Q#23 Is the pseudowire control word supported?
performance?
Q#26 Are flow labels supported? Q#24 What is the maximum rate of pseudowire encapsulation and
decapsulation? Apply the same questions as in Base Performance
for any packet based pseudowire such as IP VPN or Ethernet.
Q#27 If so, what fields are hashed on for the flow label for Q#25 Does inclusion of a pseudowire control word impact performance?
different types of pseudowires?
Q#28 Does inclusion of a flow label impact performance? Q#26 Are flow labels supported?
Entropy Label Support and Performance Q#27 If so, what fields are hashed on for the flow label for
different types of pseudowires?
Q#29 Can an entropy label be added when acting as in ingress LER Q#28 Does inclusion of a flow label impact performance?
and can it be removed when acting as an egress LER?
Q#30 If so, what fields are hashed on for the entropy label? 3.5. Entropy Label Support and Performance
Q#31 Does adding or removing an entropy label impact packet rate Q#29 Can an entropy label be added when acting as in ingress LER and
performance? can it be removed when acting as an egress LER?
Q#32 Can an entropy label be detected in the label stack, used Q#30 If so, what fields are hashed on for the entropy label?
in the hash, and properly terminate the search for further
information to hash on?
Q#33 Does using an entropy label have any negative impact on Q#31 Does adding or removing an entropy label impact packet rate
performance? It should have no impact or a positive performance?
impact.
OAM and DoS Protection Q#32 Can an entropy label be detected in the label stack, used in
the hash, and properly terminate the search for further
information to hash on?
Q#34 For each control and management plane protocol in use, what Q#33 Does using an entropy label have any negative impact on
measures are taken to provide DoS attack hardenning? Have performance? It should have no impact or a positive impact.
DoS attack tests been performed? Can compromise of an
internal computer on a management subnet be leveraged for
any form of attack including DoS attack?
Q#35 What OAM proactive and on-demand mechanisms are supported? 3.6. DoS Protection
What performance limits exist under high proactive
monitoring rates? Can excessively high proactive
monitoring rates impact control plane performance or cause
control plane instability? Ask these questions for each of
the following.
a. MPLS OAM Q#34 For each control and management plane protocol in use, what
measures are taken to provide DoS attack hardenning?
b. Pseudowire OAM Q#35 Have DoS attack tests been performed?
c. MPLS-TP OAM Q#36 Can compromise of an internal computer on a management subnet
be leveraged for any form of attack including DoS attack?
d. Layer-2 OAM Interworking 3.7. OAM Capabilities and Performance
See Section 2.6. Q#37 What OAM proactive and on-demand mechanisms are supported?
Q#38 What performance limits exist under high proactive monitoring
rates?
Q#39 Can excessively high proactive monitoring rates impact control
plane performance or cause control plane instability?
Q#40 Ask the prior questions for each of the following.
A. MPLS OAM
B. Pseudowire OAM
C. MPLS-TP OAM
D. Layer-2 OAM Interworking
See Section 2.6.2.
4. Forwarding Compliance and Performance Testing 4. Forwarding Compliance and Performance Testing
Packet rate performance of equipment supporting a large number of 10 Packet rate performance of equipment supporting a large number of 10
Gb/s or 100 Gb/s links is not possible using desktop computers or Gb/s or 100 Gb/s links is not possible using desktop computers or
workstations. The use of high end workstations as a source of test workstations. The use of high end workstations as a source of test
traffic was barely viable 20 years ago, but is no longer at all traffic was barely viable 20 years ago, but is no longer at all
viable. Though custom microcode has been used on specialized router viable. Though custom microcode has been used on specialized router
forwarding cards to serve the purpose of generating test traffic and forwarding cards to serve the purpose of generating test traffic and
measuring it, for the most part performance testing will require measuring it, for the most part performance testing will require
skipping to change at page 33, line 5 skipping to change at page 38, line 24
Performance testing is the domain of the IETF Benchmark Methodology Performance testing is the domain of the IETF Benchmark Methodology
Working Group (BMWG). Below are brief descriptions of conformance Working Group (BMWG). Below are brief descriptions of conformance
and performance tests. Some very basic tests are specified in and performance tests. Some very basic tests are specified in
[RFC5695] which partially cover only the basic performance test T#3. [RFC5695] which partially cover only the basic performance test T#3.
The following tests should be performed by the systems designer, or The following tests should be performed by the systems designer, or
deployer, or performed by the supplier on their behalf if it is not deployer, or performed by the supplier on their behalf if it is not
practical for the potential customer to perform the tests directly. practical for the potential customer to perform the tests directly.
These tests are grouped into broad categories. These tests are grouped into broad categories.
Basic Compliance The tests in Section 4.1 should be repeated under various conditions
to retest basic performance when critical capabilities are enabled.
T#1 Test forwarding at a high rate for packets with varying Complete repetition of the performance tests enabling each capability
number of label entries. While packets with more than a and combinations of capabilities would be very time intensive,
dozen label entries are unlikely to be used in any practical therefore a reduced set of performance tests can be used to gauge the
scenario today, it is useful to know if limitations exists. impact of enabling specific capabilities.
T#2 For each of the questions listed under "Basic Compliance" in 4.1. Basic Compliance
Section 3, verify the claimed compliance. For any
functionality considered critical to a deployment, where
applicable performance using each capability under load
should be verified in addition to basic compliance.
Basic Performance T#1 Test forwarding at a high rate for packets with varying number
of label entries. While packets with more than a dozen label
entries are unlikely to be used in any practical scenario today,
it is useful to know if limitations exists.
T#3 Test packet forwarding at full line rate with small packets. T#2 For each of the questions listed under "Basic Compliance" in
See [RFC5695]. The most likely case to fail is the smallest Section 3, verify the claimed compliance. For any functionality
packet size. Also test with packet sizes in four byte considered critical to a deployment, where applicable
increments ranging from payload sizes or 40 to 128 bytes. performance using each capability under load should be verified
in addition to basic compliance.
T#4 If the prior tests did not succeed for all packet sizes, 4.2. Basic Performance
then perform the following tests.
a. Increase the packet size by 4 bytes until a size is T#3 Test packet forwarding at full line rate with small packets.
found that can be forwarded at full rate. See [RFC5695]. The most likely case to fail is the smallest
packet size. Also test with packet sizes in four byte
increments ranging from payload sizes or 40 to 128 bytes.
b. Inject bursts of consecutive small packets into a stream T#4 If the prior tests did not succeed for all packet sizes, then
of larger packets. Allow some time for recovery between perform the following tests.
bursts. Increase the number of packets in the burst
until packets are dropped.
T#5 Send test traffic where a SWAP operation is required. Also A. Increase the packet size by 4 bytes until a size is found
set up multiple LSP carried over other LSP where the device that can be forwarded at full rate.
under test (DUT) is the egress of these LSP. Create test
packets such that the SWAP operation is performed after POP
operations, increasing the number of POP operations until
forwarding of small packets at full line rate can no longer
be supported. Also check to see how many POP operations can
be supported before the full set of counters can no longer
be maintained. This requirement is particularly relevant
for MPLS-TP.
T#6 Send all traffic on one LSP and see if the counters become B. Inject bursts of consecutive small packets into a stream of
inaccurate. Often counters on silicon are much smaller than larger packets. Allow some time for recovery between
the 64 bit packet and byte counters in IETF MIB. System bursts. Increase the number of packets in the burst until
developers should consider what counter polling rate is packets are dropped.
necessary to maintain accurate counters and whether those
polling rates are practical. Relevant MIBs for MPLS are
discussed in [RFC4221] and [RFC6639].
Multipath Capabilities and Performance T#5 Send test traffic where a swap operation is required. Also set
up multiple LSP carried over other LSP where the device under
test (DUT) is the egress of these LSP. Create test packets such
that the swap operation is performed after pop operations,
increasing the number of pop operations until forwarding of
small packets at full line rate can no longer be supported.
Also check to see how many pop operations can be supported
before the full set of counters can no longer be maintained.
This requirement is particularly relevant for MPLS-TP.
Multipath capabilities do not apply to MPLS-TP but apply to MPLS T#6 Send all traffic on one LSP and see if the counters become
and apply if MPLS-TP is carried in MPLS. inaccurate. Often counters on silicon are much smaller than the
64 bit packet and byte counters in IETF MIB. System developers
should consider what counter polling rate is necessary to
maintain accurate counters and whether those polling rates are
practical. Relevant MIBs for MPLS are discussed in [RFC4221]
and [RFC6639].
T#7 Send traffic at a rate well exceeding the capacity of a 4.3. Multipath Capabilities and Performance
single multipath component link, and where entropy exists
only below the top of stack. If only the top label is used
this test will fail immediately.
T#8 Move the labels with entropy down in the stack until either Multipath capabilities do not apply to MPLS-TP but apply to MPLS and
the full forwarding rate can no longer be supported or most apply if MPLS-TP is carried in MPLS.
or all packets try to use the same component link.
T#9 Repeat the two tests above with the entropy contained in IP T#7 Send traffic at a rate well exceeding the capacity of a single
headers or IP payload fields below the label stack rather multipath component link, and where entropy exists only below
than in the label stack. Test with the set of IP headers the top of stack. If only the top label is used this test will
or IP payload fields considered relevant to the deployment fail immediately.
or to the target market.
T#10 Determine whether traffic that contains a pseudowire T#8 Move the labels with entropy down in the stack until either the
control word is interpreted as IP traffic. Information in full forwarding rate can no longer be supported or most or all
the payload MUST NOT be used in the load balancing if the packets try to use the same component link.
first nibble of the packet is not 4 or 6 (IPv4 or IPv6).
T#11 Determine whether reserved labels are excluded from the T#9 Repeat the two tests above with the entropy contained in IP
label stack hash. They MUST be excluded. headers or IP payload fields below the label stack rather than
in the label stack. Test with the set of IP headers or IP
payload fields considered relevant to the deployment or to the
target market.
T#12 Perform testing in the presence of combinations of: T#10 Determine whether traffic that contains a pseudowire control
word is interpreted as IP traffic. Information in the payload
MUST NOT be used in the load balancing if the first nibble of
the packet is not 4 or 6 (IPv4 or IPv6).
a. Very large microflows. T#11 Determine whether reserved labels are excluded from the label
stack hash. They MUST be excluded.
b. Relatively short lived high capacity flows. T#12 Perform testing in the presence of combinations of:
c. Extremely large numbers of flows. A. Very large microflows.
d. Very short lived small flows. B. Relatively short lived high capacity flows.
Pseudowire Capabilities and Performance C. Extremely large numbers of flows.
T#13 Ensure that pseudowire can be set up with a pseudowire D. Very short lived small flows.
label and pseudowire control word added at ingress and the
pseudowire label and pseudowire control word removed at
egress.
T#14 For pseudowire that contains variable length payload 4.4. Pseudowire Capabilities and Performance
packets, repeat performance tests listed under "Basic
Performance" for pseudowire ingress and egress functions.
T#15 Repeat pseudowire performance tests with and without a T#13 Ensure that pseudowire can be set up with a pseudowire label
pseudowire control word. and pseudowire control word added at ingress and the pseudowire
label and pseudowire control word removed at egress.
T#16 Determine whether pseudowire can be set up with a T#14 For pseudowire that contains variable length payload packets,
pseudowire label, flow label, and pseudowire control word repeat performance tests listed under "Basic Performance" for
added at ingress and the pseudowire label, flow label, and pseudowire ingress and egress functions.
pseudowire control word removed at egress.
T#17 Determine which payload fields are used to create the flow T#15 Repeat pseudowire performance tests with and without a
label and whether the set of fields and algorithm provide pseudowire control word.
sufficient entropy for load balancing.
T#18 Repeat pseudowire performance tests with flow labels T#16 Determine whether pseudowire can be set up with a pseudowire
included. label, flow label, and pseudowire control word added at ingress
and the pseudowire label, flow label, and pseudowire control
word removed at egress.
Entropy Label Support and Performance T#17 Determine which payload fields are used to create the flow
label and whether the set of fields and algorithm provide
sufficient entropy for load balancing.
T#19 Determine whether entropy labels can be added at ingress T#18 Repeat pseudowire performance tests with flow labels included.
and removed at egress.
T#20 Determine which fields are used to create an entropy label. 4.5. Entropy Label Support and Performance
Labels further down in the stack, including entropy labels T#19 Determine whether entropy labels can be added at ingress and
further down and IP headers or IP payload fields where removed at egress.
applicable should be used. Determine whether the set of
fields and algorithm provide sufficient entropy for load
balancing.
T#21 Repeat performance tests under "Basic Performance" when T#20 Determine which fields are used to create an entropy label.
entropy labels are used, where ingress or egress is the Labels further down in the stack, including entropy labels
device under test (DUT). further down and IP headers or IP payload fields where
applicable should be used. Determine whether the set of fields
and algorithm provide sufficient entropy for load balancing.
T#22 Determine whether an ELI is detected when acting as a T#21 Repeat performance tests under "Basic Performance" when entropy
midpoint LSR and whether the search for further information labels are used, where ingress or egress is the device under
on which to base the load balancing is used. Information test (DUT).
below the entropy label SHOULD NOT be used.
T#23 Ensure that the Entropy Label Indicator and Entropy Label T#22 Determine whether an ELI is detected when acting as a midpoint
(ELI and EI) are removed from the label stack during UHP LSR and whether the search for further information on which to
and PHP operations. base the load balancing is used. Information below the entropy
label SHOULD NOT be used.
T#24 Insure that operations on the TC field when adding and T#23 Ensure that the entropy label indicator and entropy label (ELI
removing Entropy Label are correctly carried out. If TC is and EL) are removed from the label stack during UHP and PHP
changed during a SWAP operation, the ability to transfer operations.
that change MUST be provided. The ability to suppress the
transfer of TC MUST also be provided. See "pipe", "short
pipe", and "uniform" models in [RFC3443].
T#25 Repeat performance tests for midpoint LSR with entropy T#24 Insure that operations on the TC field when adding and removing
labels found at various label stack depths. entropy label are correctly carried out. If TC is changed
during a swap operation, the ability to transfer that change
MUST be provided. The ability to suppress the transfer of TC
MUST also be provided. See "pipe", "short pipe", and "uniform"
models in [RFC3443].
DoS Protection T#25 Repeat performance tests for midpoint LSR with entropy labels
found at various label stack depths.
T#26 Actively attack LSR under high protocol churn load and 4.6. DoS Protection
determine control plane performance impact or successful
DoS under test conditions. Specifically test for the
following.
a. TCP SYN attack against control plane and management T#26 Actively attack LSR under high protocol churn load and
plane protocols using TCP, including CLI access determine control plane performance impact or successful DoS
(typically SSH protected login), NETCONF, etc. under test conditions. Specifically test for the following.
b. High traffic volume attack against control plane and A. TCP SYN attack against control plane and management plane
management plane protocols not using TCP. protocols using TCP, including CLI access (typically SSH
protected login), NETCONF, etc.
c. Attacks which can be performed from a compromised B. High traffic volume attack against control plane and
management subnet computer, but not one with management plane protocols not using TCP.
authentication keys.
d. Attacks which can be performed from a compromised peer C. Attacks which can be performed from a compromised
within the control plane (internal domain and external management subnet computer, but not one with authentication
domain). Assume that per peering keys and per router keys.
ID keys rather than network wide keys are in use.
See Section 2.6.1. D. Attacks which can be performed from a compromised peer
within the control plane (internal domain and external
domain). Assume that per peering keys and per router ID
keys rather than network wide keys are in use.
OAM Capabilities and Performance See Section 2.6.1.
T#27 Determine maximum sustainable rates of BFD traffic. If BFD 4.7. OAM Capabilities and Performance
requires CPU intervention, determine both maximum rates and
CPU loading when multiple interfaces are active.
T#28 Verify LSP Ping and LSP Traceroute capability. T#27 Determine maximum sustainable rates of BFD traffic. If BFD
requires CPU intervention, determine both maximum rates and CPU
loading when multiple interfaces are active.
T#29 Determine maximum rates of MPLS-TP CC-CV traffic. If CC-CV T#28 Verify LSP Ping and LSP Traceroute capability.
requires CPU intervention, determine both maximum rates and
CPU loading when multiple interfaces are active.
T#30 Determine MPLS-TP DM precision. T#29 Determine maximum rates of MPLS-TP CC-CV traffic. If CC-CV
requires CPU intervention, determine both maximum rates and CPU
loading when multiple interfaces are active.
T#31 Determine MPLS-TP LM accuracy. T#30 Determine MPLS-TP DM precision.
T#32 Verify MPLS-TP AIS/RDI and PSC functionality, protection T#31 Determine MPLS-TP LM accuracy.
speed, and AIS/RDI notification speed when a large number
of Management Entities (ME) must be notified with AIS/RDI.
The tests in the "Basic Performance" section of the above list should T#32 Verify MPLS-TP AIS/RDI and PSC functionality, protection speed,
be repeated under various conditions to retest basic performance when and AIS/RDI notification speed when a large number of
critical capabilities are enabled. Complete repetition of the Management Entities (ME) must be notified with AIS/RDI.
performance tests enabling each capability and combinations of
capabilities would be very time intensive, therefore a reduced set of
performance tests can be used to gauge the impact of enabling
specific capabilities.
5. Acknowledgements 5. Acknowledgements
Numerous very useful comments have been received in private email. Numerous very useful comments have been received in private email.
Some of these contributions are acknowledged here, approximately in Some of these contributions are acknowledged here, approximately in
chronologic order. chronologic order.
Paul Doolan provided a brief review resulting in a number of Paul Doolan provided a brief review resulting in a number of
clarifications, most notably regarding on-chip vs. system buffering, clarifications, most notably regarding on-chip vs. system buffering,
100 Gb/s link speed assumptions in the 150 Mpps figure, and handling 100 Gb/s link speed assumptions in the 150 Mpps figure, and handling
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 extraneous methodology hints that belong in an Karthik pointed out testing methodology hints that after discussion
appendix or should be removed. were deemed out of scope and were removed.
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
the MPLS RT review.
Tal Mizrahi provided comments that prompted clarifications regarding
timestamp processing, local delivery of packets, and the need for
hardware assistance in processing OAM traffic.
6. IANA Considerations 6. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
7. Security Considerations 7. Security Considerations
This document reviews forwarding behavior specified elsewhere and This document reviews forwarding behavior specified elsewhere and
points out compliance and performance requirements. As such it points out compliance and performance requirements. As such it
introduces no new security requirements or concerns. introduces no new security requirements or concerns.
skipping to change at page 39, line 43 skipping to change at page 45, line 15
pp. 633-641., May 1995. pp. 633-641., May 1995.
[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., and A. Sajassi, "MPLS and Ethernet
OAM Interworking", draft-ietf-pwe3-mpls-eth-oam-iwk-07 OAM Interworking", draft-ietf-pwe3-mpls-eth-oam-iwk-07
(work in progress), January 2013. (work in progress), January 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-03 (work in Networks", draft-ietf-tictoc-1588overmpls-04 (work in
progress), October 2012. progress), February 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.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998. Services", RFC 2475, December 1998.
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999. "Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001. Label Switching Architecture", RFC 3031, January 2001.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001.
[RFC3429] Ohta, H., "Assignment of the 'OAM Alert Label' for [RFC3429] Ohta, H., "Assignment of the 'OAM Alert Label' for
Multiprotocol Label Switching Architecture (MPLS) Multiprotocol Label Switching Architecture (MPLS)
Operation and Maintenance (OAM) Functions", RFC 3429, Operation and Maintenance (OAM) Functions", RFC 3429,
November 2002. November 2002.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
Edge (PWE3) Architecture", RFC 3985, March 2005. Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3 [RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3
Provider-Provisioned Virtual Private Networks (PPVPNs)", Provider-Provisioned Virtual Private Networks (PPVPNs)",
RFC 4110, July 2005. RFC 4110, July 2005.
[RFC4124] Le Faucheur, F., "Protocol Extensions for Support of [RFC4124] Le Faucheur, F., "Protocol Extensions for Support of
Diffserv-aware MPLS Traffic Engineering", RFC 4124, Diffserv-aware MPLS Traffic Engineering", RFC 4124,
June 2005. June 2005.
skipping to change at page 41, line 18 skipping to change at page 46, line 46
Switched Paths (LSPs)", RFC 4875, May 2007. Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal
Cost Multipath Treatment in MPLS Networks", BCP 128, Cost Multipath Treatment in MPLS Networks", BCP 128,
RFC 4928, June 2007. RFC 4928, June 2007.
[RFC4950] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP [RFC4950] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP
Extensions for Multiprotocol Label Switching", RFC 4950, Extensions for Multiprotocol Label Switching", RFC 4950,
August 2007. August 2007.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007.
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C.
Pignataro, "The Generalized TTL Security Mechanism Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, October 2007. (GTSM)", RFC 5082, October 2007.
[RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
Connectivity Verification (VCCV): A Control Channel for Connectivity Verification (VCCV): A Control Channel for
Pseudowires", RFC 5085, December 2007. Pseudowires", RFC 5085, December 2007.
[RFC5317] Bryant, S. and L. Andersson, "Joint Working Team (JWT)
Report on MPLS Architectural Considerations for a
Transport Profile", RFC 5317, February 2009.
[RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS
Multicast Encapsulations", RFC 5332, August 2008. Multicast Encapsulations", RFC 5332, August 2008.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", RFC 5462, February 2009. Class" Field", RFC 5462, February 2009.
[RFC5695] Akhter, A., Asati, R., and C. Pignataro, "MPLS Forwarding [RFC5695] Akhter, A., Asati, R., and C. Pignataro, "MPLS Forwarding
Benchmarking Methodology for IP Flows", RFC 5695, Benchmarking Methodology for IP Flows", RFC 5695,
November 2009. November 2009.
skipping to change at page 42, line 7 skipping to change at page 47, line 43
Switched Paths (LSPs)", RFC 5884, June 2010. Switched Paths (LSPs)", RFC 5884, June 2010.
[RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding [RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding
Detection (BFD) for the Pseudowire Virtual Circuit Detection (BFD) for the Pseudowire Virtual Circuit
Connectivity Verification (VCCV)", RFC 5885, June 2010. Connectivity Verification (VCCV)", RFC 5885, June 2010.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
Time Protocol Version 4: Protocol and Algorithms Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010. Specification", RFC 5905, June 2010.
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
D., and S. Mansfield, "Guidelines for the Use of the "OAM"
Acronym in the IETF", BCP 161, RFC 6291, June 2011.
[RFC6310] Aissaoui, M., Busschbach, P., Martini, L., Morrow, M., [RFC6310] Aissaoui, M., Busschbach, P., Martini, L., Morrow, M.,
Nadeau, T., and Y(J). Stein, "Pseudowire (PW) Operations, Nadeau, T., and Y(J). Stein, "Pseudowire (PW) Operations,
Administration, and Maintenance (OAM) Message Mapping", Administration, and Maintenance (OAM) Message Mapping",
RFC 6310, July 2011. RFC 6310, July 2011.
[RFC6371] Busi, I. and D. Allan, "Operations, Administration, and [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and
Maintenance Framework for MPLS-Based Transport Networks", Maintenance Framework for MPLS-Based Transport Networks",
RFC 6371, September 2011. RFC 6371, September 2011.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
 End of changes. 189 change blocks. 
465 lines changed or deleted 751 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/