draft-ietf-mpls-forwarding-01.txt   draft-ietf-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: April 12, 2014 Contrail Systems Expires: April 14, 2014 Contrail Systems
S. Amante S. Amante
Level 3 Communications, Inc. Level 3 Communications, Inc.
A. Malis A. Malis
Verizon Verizon
C. Pignataro C. Pignataro
Cisco Cisco
October 9, 2013 October 11, 2013
MPLS Forwarding Compliance and Performance Requirements MPLS Forwarding Compliance and Performance Requirements
draft-ietf-mpls-forwarding-01 draft-ietf-mpls-forwarding-02
Abstract Abstract
This document provides guidelines for implementers regarding MPLS This document provides guidelines for implementers regarding MPLS
forwarding and a basis for evaluations of forwarding implementations. forwarding and a basis for evaluations of forwarding implementations.
Guidelines cover many aspects of MPLS forwarding. Topics are Guidelines cover many aspects of MPLS forwarding. Topics are
highlighted where implementers might potentially overlook practical highlighted where implementers might otherwise overlook practical
requirements which are unstated or under emphasized or are optional requirements which are unstated or under emphasized or are optional
for conformance to RFCs but are often considered mandatory by for conformance to RFCs but are often considered mandatory by
providers. providers.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 12, 2014. This Internet-Draft will expire on April 14, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 22 skipping to change at page 2, line 22
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction and Document Scope . . . . . . . . . . . . . . . 4 1. Introduction and Document Scope . . . . . . . . . . . . . . . 4
1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Use of Requirements Language . . . . . . . . . . . . . . . 8 1.2. Use of Requirements Language . . . . . . . . . . . . . . . 8
1.3. Apparent Misconceptions . . . . . . . . . . . . . . . . . 9 1.3. Apparent Misconceptions . . . . . . . . . . . . . . . . . 9
1.4. Target Audience . . . . . . . . . . . . . . . . . . . . . 10 1.4. Target Audience . . . . . . . . . . . . . . . . . . . . . 10
2. Forwarding Issues . . . . . . . . . . . . . . . . . . . . . . 10 2. Forwarding Issues . . . . . . . . . . . . . . . . . . . . . . 11
2.1. Forwarding Basics . . . . . . . . . . . . . . . . . . . . 11 2.1. Forwarding Basics . . . . . . . . . . . . . . . . . . . . 11
2.1.1. MPLS Special Purpose Labels . . . . . . . . . . . . . 12 2.1.1. MPLS Special Purpose Labels . . . . . . . . . . . . . 12
2.1.2. MPLS Differentiated Services . . . . . . . . . . . . . 12 2.1.2. MPLS Differentiated Services . . . . . . . . . . . . . 13
2.1.3. Time Synchronization . . . . . . . . . . . . . . . . . 13 2.1.3. Time Synchronization . . . . . . . . . . . . . . . . . 14
2.1.4. Uses of Multiple Label Stack Entries . . . . . . . . . 14 2.1.4. Uses of Multiple Label Stack Entries . . . . . . . . . 14
2.1.5. MPLS Link Bundling . . . . . . . . . . . . . . . . . . 15 2.1.5. MPLS Link Bundling . . . . . . . . . . . . . . . . . . 15
2.1.6. MPLS Hierarchy . . . . . . . . . . . . . . . . . . . . 15 2.1.6. MPLS Hierarchy . . . . . . . . . . . . . . . . . . . . 15
2.1.7. MPLS Fast Reroute (FRR) . . . . . . . . . . . . . . . 15 2.1.7. MPLS Fast Reroute (FRR) . . . . . . . . . . . . . . . 16
2.1.8. Pseudowire Encapsulation . . . . . . . . . . . . . . . 16 2.1.8. Pseudowire Encapsulation . . . . . . . . . . . . . . . 16
2.1.8.1. Pseudowire Sequence Number . . . . . . . . . . . . 16 2.1.8.1. Pseudowire Sequence Number . . . . . . . . . . . . 17
2.1.9. Layer-2 and Layer-3 VPN . . . . . . . . . . . . . . . 17 2.1.9. Layer-2 and Layer-3 VPN . . . . . . . . . . . . . . . 18
2.2. MPLS Multicast . . . . . . . . . . . . . . . . . . . . . . 18 2.2. MPLS Multicast . . . . . . . . . . . . . . . . . . . . . . 18
2.3. Packet Rates . . . . . . . . . . . . . . . . . . . . . . . 18 2.3. Packet Rates . . . . . . . . . . . . . . . . . . . . . . . 19
2.4. MPLS Multipath Techniques . . . . . . . . . . . . . . . . 20 2.4. MPLS Multipath Techniques . . . . . . . . . . . . . . . . 21
2.4.1. Pseudowire Control Word . . . . . . . . . . . . . . . 21 2.4.1. Pseudowire Control Word . . . . . . . . . . . . . . . 21
2.4.2. Large Microflows . . . . . . . . . . . . . . . . . . . 22 2.4.2. Large Microflows . . . . . . . . . . . . . . . . . . . 22
2.4.3. Pseudowire Flow Label . . . . . . . . . . . . . . . . 22 2.4.3. Pseudowire Flow Label . . . . . . . . . . . . . . . . 22
2.4.4. MPLS Entropy Label . . . . . . . . . . . . . . . . . . 22 2.4.4. MPLS Entropy Label . . . . . . . . . . . . . . . . . . 23
2.4.5. Fields Used for Multipath Load Balance . . . . . . . . 23 2.4.5. Fields Used for Multipath Load Balance . . . . . . . . 23
2.4.5.1. MPLS Fields in Multipath . . . . . . . . . . . . . 23 2.4.5.1. MPLS Fields in Multipath . . . . . . . . . . . . . 23
2.4.5.2. IP Fields in Multipath . . . . . . . . . . . . . . 25 2.4.5.2. IP Fields in Multipath . . . . . . . . . . . . . . 25
2.4.5.3. Fields Used in Flow Label . . . . . . . . . . . . 26 2.4.5.3. Fields Used in Flow Label . . . . . . . . . . . . 27
2.4.5.4. Fields Used in Entropy Label . . . . . . . . . . . 27 2.4.5.4. Fields Used in Entropy Label . . . . . . . . . . . 27
2.5. MPLS-TP and UHP . . . . . . . . . . . . . . . . . . . . . 27 2.5. MPLS-TP and UHP . . . . . . . . . . . . . . . . . . . . . 27
2.6. Local Delivery of Packets . . . . . . . . . . . . . . . . 27 2.6. Local Delivery of Packets . . . . . . . . . . . . . . . . 28
2.6.1. DoS Protection . . . . . . . . . . . . . . . . . . . . 28 2.6.1. DoS Protection . . . . . . . . . . . . . . . . . . . . 28
2.6.2. MPLS OAM . . . . . . . . . . . . . . . . . . . . . . . 30 2.6.2. MPLS OAM . . . . . . . . . . . . . . . . . . . . . . . 30
2.6.3. Pseudowire OAM . . . . . . . . . . . . . . . . . . . . 31 2.6.3. Pseudowire OAM . . . . . . . . . . . . . . . . . . . . 31
2.6.4. MPLS-TP OAM . . . . . . . . . . . . . . . . . . . . . 31 2.6.4. MPLS-TP OAM . . . . . . . . . . . . . . . . . . . . . 31
2.6.5. MPLS OAM and Layer-2 OAM Interworking . . . . . . . . 32 2.6.5. MPLS OAM and Layer-2 OAM Interworking . . . . . . . . 33
2.6.6. Extent of OAM Support by Hardware . . . . . . . . . . 33 2.6.6. Extent of OAM Support by Hardware . . . . . . . . . . 33
2.7. Number and Size of Flows . . . . . . . . . . . . . . . . . 34 2.7. Number and Size of Flows . . . . . . . . . . . . . . . . . 34
3. Questions for Suppliers . . . . . . . . . . . . . . . . . . . 34 3. Questions for Suppliers . . . . . . . . . . . . . . . . . . . 35
3.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . . 35 3.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . . 35
3.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 36 3.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 36
3.3. Multipath Capabilities and Performance . . . . . . . . . . 37 3.3. Multipath Capabilities and Performance . . . . . . . . . . 37
3.4. Pseudowire Capabilities and Performance . . . . . . . . . 37 3.4. Pseudowire Capabilities and Performance . . . . . . . . . 38
3.5. Entropy Label Support and Performance . . . . . . . . . . 38 3.5. Entropy Label Support and Performance . . . . . . . . . . 38
3.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . . 38 3.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . . 38
3.7. OAM Capabilities and Performance . . . . . . . . . . . . . 38 3.7. OAM Capabilities and Performance . . . . . . . . . . . . . 39
4. Forwarding Compliance and Performance Testing . . . . . . . . 39 4. Forwarding Compliance and Performance Testing . . . . . . . . 39
4.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . . 39 4.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . . 40
4.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 40 4.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 40
4.3. Multipath Capabilities and Performance . . . . . . . . . . 41 4.3. Multipath Capabilities and Performance . . . . . . . . . . 41
4.4. Pseudowire Capabilities and Performance . . . . . . . . . 41 4.4. Pseudowire Capabilities and Performance . . . . . . . . . 42
4.5. Entropy Label Support and Performance . . . . . . . . . . 42 4.5. Entropy Label Support and Performance . . . . . . . . . . 42
4.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . . 43 4.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . . 43
4.7. OAM Capabilities and Performance . . . . . . . . . . . . . 43 4.7. OAM Capabilities and Performance . . . . . . . . . . . . . 43
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
7. Security Considerations . . . . . . . . . . . . . . . . . . . 44 7. Security Considerations . . . . . . . . . . . . . . . . . . . 45
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45
8.1. Normative References . . . . . . . . . . . . . . . . . . . 45 8.1. Normative References . . . . . . . . . . . . . . . . . . . 45
8.2. Informative References . . . . . . . . . . . . . . . . . . 46 8.2. Informative References . . . . . . . . . . . . . . . . . . 46
Appendix A. Organization of References Section . . . . . . . . . 51 Appendix A. Organization of References Section . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51
1. Introduction and Document Scope 1. Introduction and Document Scope
The initial purpose of this document was to address concerns raised The initial purpose of this document was to address concerns raised
on the MPLS WG mailing list about shortcomings in implementations of on the MPLS WG mailing list about shortcomings in implementations of
skipping to change at page 8, line 40 skipping to change at page 8, line 40
VLAN Virtual Local Area Network (Ethernet) VLAN Virtual Local Area Network (Ethernet)
VOQ Virtual Output Queuing (switch fabric design) VOQ Virtual Output Queuing (switch fabric design)
VPN Virtual Private Network VPN Virtual Private Network
WG Working Group WG Working Group
1.2. Use of Requirements Language 1.2. Use of Requirements Language
This document is informational. The key words "MUST", "MUST NOT", This document is informational. The upper case [RFC2119] key words
"REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", are not used in this document, except in the following cases.
"RECOMMENDED", "MAY", and "OPTIONAL" are used only where the
requirement is specified in an existing RFC. These keywords SHOULD
be interpreted as described in RFC 2119 [RFC2119].
Advice given in this document does not use the upper case RFC 2119 1. RFC 2119 keywords are used where requirements stated in this
keywords, except where explicitly noted that the keywords indicate document are called for in referenced RFCs. In most cases the
that operator experiences indicate a requirement, but there are no RFC containing the requirement is cited within the statement
existing RFC requirements. Such advice may be ignored by using an RFC 2119 keyword.
implementations. Similarly, implementations not claiming conformance
to specific RFCs may ignore the requirements of those RFCs. In both 2. RFC 2119 keywords are used where explicitly noted that the
cases, implementers should consider the risk of doing so. keywords indicate that operator experiences indicate a
requirement, but there are no existing RFC requirements.
Advice provided by this document may be ignored by implementations.
Similarly, implementations not claiming conformance to specific RFCs
may ignore the requirements of those RFCs. In both cases,
implementers should consider the risk of doing so.
1.3. Apparent Misconceptions 1.3. Apparent Misconceptions
In early generations of forwarding silicon (which might now be behind In early generations of forwarding silicon (which might now be behind
us), there apparently were some misconceptions about MPLS. The us), there apparently were some misconceptions about MPLS. The
following statements provide clarifications. following statements provide clarifications.
1. There are practical reasons to have more than one or two labels 1. There are practical reasons to have more than one or two labels
in an MPLS label stack. Under some circumstances the label stack in an MPLS label stack. Under some circumstances the label stack
can become quite deep. See Section 2.1. can become quite deep. See Section 2.1.
skipping to change at page 11, line 5 skipping to change at page 11, line 9
The implementer, systems designer, and deployer have a transitive The implementer, systems designer, and deployer have a transitive
supplier customer relationship. It is in the best interest of the supplier customer relationship. It is in the best interest of the
supplier to review their product against their customer's checklist supplier to review their product against their customer's checklist
and customer's customer's checklist if applicable. and customer's customer's checklist if applicable.
2. Forwarding Issues 2. Forwarding Issues
A brief review of forwarding issues is provided in the subsections A brief review of forwarding issues is provided in the subsections
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 is
testing is covered in the following sections, Section 3 and covered in Section 3. Some guidelines for testing are provided in
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 are 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].
skipping to change at page 11, line 33 skipping to change at page 11, line 37
3. Differentiated Services is supported by [RFC3270] and [RFC4124]. 3. Differentiated Services is supported by [RFC3270] and [RFC4124].
The "EXP" field is renamed to "Traffic Class" in [RFC5462], The "EXP" field is renamed to "Traffic Class" in [RFC5462],
removing any misconception that it was available for removing any misconception that it was available for
experimentation or could be ignored. experimentation or could be ignored.
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].
6. [RFC5332] redefines the two data link layer codepoints for MPLS
packets.
Tunneling encapsulations which may carry MPLS, such as MPLS in GRE,
L2TP, or LDP, are out of scope.
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 (ELI) and entropy label (EL) are 2. The entropy label indicator (ELI) and entropy label (EL) are
defined by [RFC6790]. defined by [RFC6790].
A few RFCs update RFC3209. Those that are listed as updating RFC3209 A few RFCs update RFC3209. Those that are listed as updating RFC3209
skipping to change at page 14, line 31 skipping to change at page 14, line 39
MPLS deployments in the early part of the prior decade (circa 2000) MPLS deployments in the early part of the prior decade (circa 2000)
tended to support either LDP or RSVP-TE. LDP was favored by some for tended to support either LDP or RSVP-TE. LDP was favored by some for
its ability to scale to a very large number of PE devices at the edge its ability to scale to a very large number of PE devices at the edge
of the network, without adding deployment complexity. RSVP-TE was of the network, without adding deployment complexity. RSVP-TE was
favored, generally in the network core, where traffic engineering favored, generally in the network core, where traffic engineering
and/or fast reroute were considered important. and/or fast reroute were considered important.
Both LDP and RSVP-TE are used simultaneously within major Service Both LDP and RSVP-TE are used simultaneously within major Service
Provider networks using a technique known as "LDP over RSVP-TE Provider networks using a technique known as "LDP over RSVP-TE
Tunneling". This technique allows service providers to carry LDP Tunneling". This technique allows service providers to carry LDP
tunnels, originating and terminating at PEs, inside of RSVP-TE tunnels inside RSVP-TE tunnels. This makes it possible to take
tunnels, generally between Inter-City P routers, to take advantage of advantage of the Traffic Engineering and Fast Re-Route on more
Traffic Engineering and Fast Re-Route on more expensive Inter-City expensive Inter-City and Inter-Continental transport paths. The
and Inter-Continental Transport paths. LDP over RSVP-TE tunneling ingress RSVP-TE PEs places many LDP tunnels on a single RSVP-TE LSP
requires a minimum of two MPLS labels: one each for LDP and RSVP-TE. and carries it to the egress RSVP-TE PE. The LDP PEs are situated
further from the core, for example within a metro network. LDP over
RSVP-TE tunneling requires a minimum of two MPLS labels: one each for
LDP and RSVP-TE.
The use of MPLS FRR [RFC4090] might add one more label to MPLS The use of MPLS FRR [RFC4090] might add one more label to MPLS
traffic, but only when FRR protection is in use (active). If LDP traffic, but only when FRR protection is in use (active). If LDP
over RSVP-TE is in use, and FRR protection is in use, then at least over RSVP-TE is in use, and FRR protection is in use, then at least
three MPLS labels are present on the label stack on the links through three MPLS labels are present on the label stack on the links through
which the Bypass LSP traverses. FRR is covered in Section 2.1.7. which the Bypass LSP traverses. FRR is covered in Section 2.1.7.
LDP L2VPN, LDP IPVPN, BGP L2VPN, and BGP IPVPN added support for VPN LDP L2VPN, LDP IPVPN, BGP L2VPN, and BGP IPVPN added support for VPN
services that are deployed in the vast majority of service providers. services that are deployed by the vast majority of service providers.
These VPN services added yet another label, bringing the label stack These VPN services added yet another label, bringing the label stack
depth (when FRR is active) to four. depth (when FRR is active) to four.
Pseudowires and VPN are discussed in further detail in Section 2.1.8 Pseudowires and VPN are discussed in further detail in Section 2.1.8
and Section 2.1.9. and Section 2.1.9.
MPLS hierarchy as described in [RFC4206] can in principle add up to MPLS hierarchy as described in [RFC4206] can in principle add up to
four additional labels. MPLS hierarchy is discussed in four additional labels. MPLS hierarchy is discussed in
Section 2.1.6. Section 2.1.6.
skipping to change at page 17, line 49 skipping to change at page 18, line 14
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 two labels to the MPLS label
The need to provide a useful entropy label value impacts the stack. 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
skipping to change at page 19, line 9 skipping to change at page 19, line 21
2.3. Packet Rates 2.3. Packet Rates
While average packet size of Internet traffic may be large, long While average packet size of Internet traffic may be large, long
sequences of small packets have both been predicted in theory and sequences of small packets have both been predicted in theory and
observed in practice. Traffic compression and TCP ACK compression observed in practice. Traffic compression and TCP ACK compression
can conspire to create long sequences of packets of 40-44 bytes in can conspire to create long sequences of packets of 40-44 bytes in
payload length. If carried over Ethernet, the 64 byte minimum payload length. If carried over Ethernet, the 64 byte minimum
payload applies, yielding a packet rate of approximately 150 Mpps payload applies, yielding a packet rate of approximately 150 Mpps
(million packets per second) for the duration of the burst on a (million packets per second) for the duration of the burst on a
nominal 100 Gb/s link. The peak rate is higher for other nominal 100 Gb/s link. The peak rate for other encapsulations can be
encapsulations and can be as high as 250 Mpps (for example IP or MPLS as high as 250 Mpps (for example IP or MPLS encapsulated using GFP
encapsulated using GFP over OTN ODU4). over OTN ODU4).
It is also possible that the packet rates for a minimum payload size, It is possible that the packet rates achieved by a specific
such as 64 byte (64B) payload for Ethernet, is acceptable, but the implementation is acceptable for a minimum payload size, such as 64
rate declines for other packet sizes, such as 65B payload. There are byte (64B) payload for Ethernet, but the acheived rate declines to an
other packet rates of interest besides TCP ACK. For example, a TCP unacceptable level for other packet sizes, such as 65B payload.
ACK carried over an Ethernet PW over MPLS over Ethernet may occupy There are other packet rates of interest besides TCP ACK. For
82B or 82B plus an increment of 4B if additional MPLS labels are example, a TCP ACK carried over an Ethernet PW over MPLS over
present. Ethernet may occupy 82B or 82B plus an increment of 4B if additional
MPLS labels are present.
A graph of packet rate vs. packet size often displays a sawtooth. A graph of packet rate vs. packet size often displays a sawtooth.
The sawtooth is commonly due to a memory bottleneck and memory The sawtooth is commonly due to a memory bottleneck and memory
widths, sometimes internal cache, but often a very wide external widths, sometimes internal cache, but often a very wide external
buffer memory interface. In some cases it may be due to a fabric buffer memory interface. In some cases it may be due to a fabric
transfer width. A fine packing, rounding up to the nearest 8B or 16B transfer width. A fine packing, rounding up to the nearest 8B or 16B
will result in a fine sawtooth with small degradation for 65B, and will result in a fine sawtooth with small degradation for 65B, and
even less for 82B packets. A course packing, rounding up to 64B can even less for 82B packets. A course packing, rounding up to 64B can
yield a sharper drop in performance for 65B packets, or perhaps more yield a sharper drop in performance for 65B packets, or perhaps more
important, a larger drop for 82B packets. important, a larger drop for 82B packets.
skipping to change at page 32, line 51 skipping to change at page 33, line 13
assistance for BFD processing helps insure that protection recovery assistance for BFD processing helps insure that protection recovery
time requirements can be met even for faults affecting a large number time requirements can be met even for faults affecting a large number
of LSP. 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 [RFC7023] specifies the mapping of defect states
of defect states between many types of hardware Attachment Circuits between many types of hardware Attachment Circuits (ACs) and
(ACs) and associated Pseudowires (PWs). This functionality SHOULD be associated Pseudowires (PWs). This functionality SHOULD be supported
supported in forwarding hardware. in forwarding hardware.
It is beneficial if an MPLS OAM implementation can interwork with the It is beneficial if an MPLS OAM implementation can interwork with the
underlying server layer and provide a means to interwork with a underlying server layer and provide a means to interwork with a
client layer. For example, [RFC6427] specifies an inter-layer client layer. For example, [RFC6427] specifies an inter-layer
propagation of AIS and LDI from MPLS server layer to client MPLS propagation of AIS and LDI from MPLS server layer to client MPLS
layers. Where the server layer is a Layer-2, such as Ethernet, PPP layers. Where the server layer is a Layer-2, such as Ethernet, PPP
over SONET/SDH, or GFP over OTN, interwork among layers is also over SONET/SDH, or GFP over OTN, interwork among layers is also
beneficial. For high speed interfaces, supporting this interworking beneficial. For high speed interfaces, supporting this interworking
in forwarding hardware helps insure that protection based on this in forwarding hardware helps insure that protection based on this
interworking can meet recovery time requirements even for faults interworking can meet recovery time requirements even for faults
skipping to change at page 46, line 36 skipping to change at page 46, line 46
"Dynamics of TCP Traffic over ATM Networks", IEEE Journal "Dynamics of TCP Traffic over ATM Networks", IEEE Journal
of Special Areas of Communication Vol 13 No 4, May 1995, of Special Areas of Communication Vol 13 No 4, May 1995,
pp. 633-641., May 1995. pp. 633-641., May 1995.
[I-D.ietf-mpls-special-purpose-labels] [I-D.ietf-mpls-special-purpose-labels]
Kompella, K., Andersson, L., and A. Farrel, "Allocating Kompella, K., Andersson, L., and A. Farrel, "Allocating
and Retiring Special Purpose MPLS Labels", and Retiring Special Purpose MPLS Labels",
draft-ietf-mpls-special-purpose-labels-03 (work in draft-ietf-mpls-special-purpose-labels-03 (work in
progress), July 2013. progress), July 2013.
[I-D.ietf-pwe3-mpls-eth-oam-iwk]
Mohan, D., Bitar, N., Sajassi, A., DeLord, S., Niger, P.,
and R. Qiu, "MPLS and Ethernet OAM Interworking",
draft-ietf-pwe3-mpls-eth-oam-iwk-08 (work in progress),
July 2013.
[I-D.ietf-pwe3-vccv-impl-survey-results] [I-D.ietf-pwe3-vccv-impl-survey-results]
Malis, A., "The Pseudowire (PW) & Virtual Circuit Malis, A., "The Pseudowire (PW) & Virtual Circuit
Connectivity Verification (VCCV) Implementation Survey Connectivity Verification (VCCV) Implementation Survey
Results", draft-ietf-pwe3-vccv-impl-survey-results-03 Results", draft-ietf-pwe3-vccv-impl-survey-results-03
(work in progress), October 2013. (work in progress), October 2013.
[I-D.ietf-tictoc-1588overmpls] [I-D.ietf-tictoc-1588overmpls]
Davari, S., Oren, A., Bhatia, M., Roberts, P., and L. Davari, S., Oren, A., Bhatia, M., Roberts, P., and L.
Montini, "Transporting Timing messages over MPLS Montini, "Transporting Timing messages over MPLS
Networks", draft-ietf-tictoc-1588overmpls-05 (work in Networks", draft-ietf-tictoc-1588overmpls-05 (work in
skipping to change at page 51, line 14 skipping to change at page 51, line 19
[RFC6720] Pignataro, C. and R. Asati, "The Generalized TTL Security [RFC6720] Pignataro, C. and R. Asati, "The Generalized TTL Security
Mechanism (GTSM) for the Label Distribution Protocol Mechanism (GTSM) for the Label Distribution Protocol
(LDP)", RFC 6720, August 2012. (LDP)", RFC 6720, August 2012.
[RFC6829] Chen, M., Pan, P., Pignataro, C., and R. Asati, "Label [RFC6829] Chen, M., Pan, P., Pignataro, C., and R. Asati, "Label
Switched Path (LSP) Ping for Pseudowire Forwarding Switched Path (LSP) Ping for Pseudowire Forwarding
Equivalence Classes (FECs) Advertised over IPv6", Equivalence Classes (FECs) Advertised over IPv6",
RFC 6829, January 2013. RFC 6829, January 2013.
[RFC7023] Mohan, D., Bitar, N., Sajassi, A., DeLord, S., Niger, P.,
and R. Qiu, "MPLS and Ethernet Operations, Administration,
and Maintenance (OAM) Interworking", RFC 7023,
October 2013.
Appendix A. Organization of References Section Appendix A. Organization of References Section
The References section is split into Normative and Informative The References section is split into Normative and Informative
subsections. References that directly specify forwarding subsections. References that directly specify forwarding
encapsulations or behaviors are listed as normative. References encapsulations or behaviors are listed as normative. References
which describe signaling only, though normative with respect to which describe signaling only, though normative with respect to
signaling, are listed as informative. They are informative with signaling, are listed as informative. They are informative with
respect to MPLS forwarding. respect to MPLS forwarding.
Authors' Addresses Authors' Addresses
 End of changes. 32 change blocks. 
65 lines changed or deleted 77 lines changed or added

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