< draft-ietf-mpls-forwarding-03.txt   draft-ietf-mpls-forwarding-04.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: May 18, 2014 Juniper Networks Expires: June 20, 2014 Juniper Networks
S. Amante S. Amante
Apple Inc. Apple Inc.
A. Malis A. Malis
Consultant Consultant
C. Pignataro C. Pignataro
Cisco Cisco
November 14, 2013 December 17, 2013
MPLS Forwarding Compliance and Performance Requirements MPLS Forwarding Compliance and Performance Requirements
draft-ietf-mpls-forwarding-03 draft-ietf-mpls-forwarding-04
Abstract Abstract
This document provides guidelines for implementers regarding MPLS This document provides guidelines for implementers regarding MPLS
forwarding and a basis for evaluations of forwarding implementations. forwarding and a basis for evaluations of forwarding implementations.
Guidelines cover many aspects of MPLS forwarding. Topics are Guidelines cover many aspects of MPLS forwarding. Topics are
highlighted where implementers might otherwise overlook practical highlighted where implementers might otherwise overlook practical
requirements which are unstated or under emphasized or are optional requirements which are unstated or under emphasized or are optional
for conformance to RFCs but are often considered mandatory by for conformance to RFCs but are often considered mandatory by
providers. providers.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 18, 2014. This Internet-Draft will expire on June 20, 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 38 skipping to change at page 2, line 38
2.1. Forwarding Basics . . . . . . . . . . . . . . . . . . . . 10 2.1. Forwarding Basics . . . . . . . . . . . . . . . . . . . . 10
2.1.1. MPLS Special Purpose Labels . . . . . . . . . . . . . 11 2.1.1. MPLS Special Purpose Labels . . . . . . . . . . . . . 11
2.1.2. MPLS Differentiated Services . . . . . . . . . . . . 12 2.1.2. MPLS Differentiated Services . . . . . . . . . . . . 12
2.1.3. Time Synchronization . . . . . . . . . . . . . . . . 13 2.1.3. Time Synchronization . . . . . . . . . . . . . . . . 13
2.1.4. Uses of Multiple Label Stack Entries . . . . . . . . 14 2.1.4. Uses of Multiple Label Stack Entries . . . . . . . . 14
2.1.5. MPLS Link Bundling . . . . . . . . . . . . . . . . . 15 2.1.5. MPLS Link Bundling . . . . . . . . . . . . . . . . . 15
2.1.6. MPLS Hierarchy . . . . . . . . . . . . . . . . . . . 15 2.1.6. MPLS Hierarchy . . . . . . . . . . . . . . . . . . . 15
2.1.7. MPLS Fast Reroute (FRR) . . . . . . . . . . . . . . . 15 2.1.7. MPLS Fast Reroute (FRR) . . . . . . . . . . . . . . . 15
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 . . . . . . . . . . . 16
2.1.9. Layer-2 and Layer-3 VPN . . . . . . . . . . . . . . . 17 2.1.9. Layer-2 and Layer-3 VPN . . . . . . . . . . . . . . . 18
2.2. MPLS Multicast . . . . . . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . 22
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 . . . . . . . . . . . . . . . . 23
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 . . . . . . . . . . . . 24
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 . . . . . . . . . . 26 2.4.5.4. Fields Used in Entropy Label . . . . . . . . . . 27
2.5. MPLS-TP and UHP . . . . . . . . . . . . . . . . . . . . . 27 2.5. MPLS-TP and UHP . . . . . . . . . . . . . . . . . . . . . 28
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 . . . . . . . . . . . . . . . . . . . . . 32
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 . . . . . . . . . . . . . . . . . . . . 34 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 . . . . . . . . . 40 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 . . . . . . . . . . . . . . . . . . . . . 42 4.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . 43
4.7. OAM Capabilities and Performance . . . . . . . . . . . . 43 4.7. OAM Capabilities and Performance . . . . . . . . . . . . 43
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
7. Security Considerations . . . . . . . . . . . . . . . . . . . 44 7. Security Considerations . . . . . . . . . . . . . . . . . . . 45
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 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
MPLS forwarding. Documenting existing misconceptions and potential MPLS forwarding. Documenting existing misconceptions and potential
skipping to change at page 12, line 7 skipping to change at page 12, line 7
general purpose CPU or other highly programmable hardware. For general purpose CPU or other highly programmable hardware. For
example, ELI will only be sent to LSR which have signaled support for example, ELI will only be sent to LSR which have signaled support for
[RFC6790] and high OAM packet rate must be negotiated among [RFC6790] and high OAM packet rate must be negotiated among
endpoints. endpoints.
[RFC3429] reserves a label for ITU-T Y.1711, however Y.1711 does not [RFC3429] reserves a label for ITU-T Y.1711, however Y.1711 does not
work with multipath and its use is strongly discouraged. work with multipath and its use is strongly discouraged.
The current list of special purpose labels can be found on the The current list of special purpose labels can be found on the
"Multiprotocol Label Switching Architecture (MPLS) Label Values" "Multiprotocol Label Switching Architecture (MPLS) Label Values"
registry reachable at IANA's pages at [1]. registry reachable at IANA's pages at http://www.iana.org.
[I-D.ietf-mpls-special-purpose-labels] introduces an IANA "Extended [I-D.ietf-mpls-special-purpose-labels] introduces an IANA "Extended
Special Purpose MPLS Label Values" registry and makes use of the Special Purpose MPLS Label Values" registry and makes use of the
"extension" label, label 15, to indicate that the next label is an "extension" label, label 15, to indicate that the next label is an
extended special purpose label and requires special handling. The extended special purpose label and requires special handling. The
range of only 16 values for special purpose labels allows a table to range of only 16 values for special purpose labels allows a table to
be used. The range of extended special purpose labels with 20 bits be used. The range of extended special purpose labels with 20 bits
available for use may have to be handled in some other way in the available for use may have to be handled in some other way in the
unlikely event that in the future the range of currently reserved unlikely event that in the future the range of currently reserved
values 256-1048575 are used. If only the standards action range, values 256-1048575 are used. If only the standards action range,
skipping to change at page 16, line 35 skipping to change at page 16, line 35
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 lossless and/or in-order
Resequencing support, rather than dropping at egress on out of order delivery. Identifying lost PW packets and exact amount of lost
arrival, is most important for PW payload types with a high payload is critical for PW services which maintain bit timing, such
expectation of lossless delivery. For example, TDM payloads require as Time Division Multiplexing (TDM) services since these services
sequence number support and require resequencing support. The same MUST compensate lost payload on a bit-for-bit basis.
is true of ATM CBR service. ATM VBR or ABR may have somewhat relaxed
requirements, but generally require ATM Early Packet Discard (EPD) or With PW services which maintain bit timing, packets that have been
ATM Partial Packet Discard (PPD) [ATM-EPD-and-PPD]. Though sequence received out of order also MUST be identified and may be either re-
number support and resequencing support are beneficial to PW packet ordered or dropped. Reordering requires, in addition to sequence
oriented payloads such as FR and Ethernet, they are highly desirable numbering, a "reorder buffer" in the egress PE, and ability to
but not as strongly required. reorder is limited by the depth of this buffer. The down side of
maintaining a large reorder buffer is added end-to-end service delay.
For PW services which maintain bit timing or any other service where
jitter must be bounded, a jitter buffer is always necessary. The
jitter buffer is needed regardless of whether reordering is done. In
order to be effective, a reorder buffer must often be larger than a
jitter buffer needs to be creating a tradeoff between reducing loss
and minimizing delay.
PW services which are not timing critical bit streams in nature are
cell oriented or frame oriented. Though resequencing support may be
beneficial to PW cell and frame oriented payloads such as ATM, FR and
Ethernet, this support is desirable but not required. Requirements
to hamdle out of order packets at all vary among services and
deployments. For example for Ethernet PW, occasional (very rare)
reordering is usually acceptable. If the Ethernet PW is carrying
MPLS-TP, then this reordering may be acceptable.
Reducing jitter is best done by an end-system, given that the
tradeoff of loss vs delay varies among services. For example with
interactive real time services low delay is preferred, while with
non-interactive (one way) real time services low loss is preferred.
The same end-site may be receiving both types of traffic. Regardless
of this, bounded jitter is sometimes a requiremnet for specific
deployments.
Packet reorder should be rare except in a small number of Packet reorder should be rare except in a small number of
circumstances, most of which are due to network design or equipment circumstances, most of which are due to network design or equipment
design errors: design errors:
1. The most common case is where reordering occurs is rare, 1. The most common case is where reordering occurs is rare,
occurring only when a network or equipment fault forces traffic occurring only when a network or equipment fault forces traffic
on a new path with different delay. The packet loss that on a new path with different delay. The packet loss that
accompanies a network or equipment fault is generally more accompanies a network or equipment fault is generally more
disruptive than any reordering which may occur. disruptive than any reordering which may occur.
skipping to change at page 17, line 30 skipping to change at page 18, line 5
4. Another avoidable case is where some core equipment has multipath 4. Another avoidable case is where some core equipment has multipath
and for some reason insists on periodically installing a new and for some reason insists on periodically installing a new
random number as the multipath hash seed. If supporting MPLS-TP, random number as the multipath hash seed. If supporting MPLS-TP,
equipment MUST provide a means to disable periodic hash reseeding equipment MUST provide a means to disable periodic hash reseeding
and deployments MUST disable periodic hash reseeding. Even if and deployments MUST disable periodic hash reseeding. Even if
not supporting MPLS-TP, equipment should provide a means to not supporting MPLS-TP, equipment should provide a means to
disable periodic hash reseeding and deployments should disable disable periodic hash reseeding and deployments should disable
periodic hash reseeding. periodic hash reseeding.
In provider networks which use multipath techniques and which may
occassionally rebalance traffic or which may change PW paths
occasionally for other reasons, reordering may be far more common
than loss. Where reordering is more common than loss, resequencing
packets is beneficial, rather than dropping packets at egress when
out of order arrival occus. Resequencing is most important for PW
payload types with a high expectation of lossless delivery since in
such cases out of order delivery within the network results in PW
loss.
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 two labels to the MPLS label label) which would add an additional two labels to the MPLS label
skipping to change at page 44, line 24 skipping to change at page 44, line 50
also provided a number of clarifications to the questions and tests also provided a number of clarifications to the questions and tests
in Section 3 and Section 4. in Section 3 and Section 4.
Gregory Mirsky and Thomas Beckhaus provided useful comments during Gregory Mirsky and Thomas Beckhaus provided useful comments during
the MPLS RT review. the MPLS RT review.
Tal Mizrahi provided comments that prompted clarifications regarding Tal Mizrahi provided comments that prompted clarifications regarding
timestamp processing, local delivery of packets, and the need for timestamp processing, local delivery of packets, and the need for
hardware assistance in processing OAM traffic. hardware assistance in processing OAM traffic.
Alexander (Sasha) Vainshtein pointed out errors in Section 2.1.8.1
and suggested new text which after lengthy discussion resulted in
restating the sumarization of requirements from PWE3 RFCs and more
clearly stating the benefits and drawbacks of packet resequencing
based on PW sequence number.
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 46, line 17 skipping to change at page 46, line 42
RFC 6790, November 2012. RFC 6790, November 2012.
8.2. Informative References 8.2. Informative References
[ACK-compression] [ACK-compression]
, , , "Observations and Dynamics of a Congestion Control , , , "Observations and Dynamics of a Congestion Control
Algorithm: The Effects of Two-Way Traffic", Proc. ACM Algorithm: The Effects of Two-Way Traffic", Proc. ACM
SIGCOMM, ACM Computer Communications Review (CCR) Vol 21, SIGCOMM, ACM Computer Communications Review (CCR) Vol 21,
No 4, 1991, pp.133-147., 1991. No 4, 1991, pp.133-147., 1991.
[ATM-EPD-and-PPD]
, "Dynamics of TCP Traffic over ATM Networks", IEEE
Journal of Special Areas of Communication Vol 13 No 4, 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", draft-ietf- and Retiring Special Purpose MPLS Labels", draft-ietf-
mpls-special-purpose-labels-03 (work in progress), July mpls-special-purpose-labels-03 (work in progress), July
2013. 2013.
[I-D.ietf-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
 End of changes. 21 change blocks. 
47 lines changed or deleted 83 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/