draft-ietf-mpls-in-udp-09.txt   draft-ietf-mpls-in-udp-10.txt 
Network Working Group X. Xu Network Working Group X. Xu
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Standards Track N. Sheth Intended status: Standards Track N. Sheth
Expires: June 21, 2015 Juniper Networks Expires: July 18, 2015 Juniper Networks
L. Yong L. Yong
Huawei USA Huawei USA
R. Callon R. Callon
Juniper Networks Juniper Networks
D. Black D. Black
EMC Corporation EMC Corporation
December 18, 2014 January 14, 2015
Encapsulating MPLS in UDP Encapsulating MPLS in UDP
draft-ietf-mpls-in-udp-09 draft-ietf-mpls-in-udp-10
Abstract Abstract
This document specifies an IP-based encapsulation for MPLS, called This document specifies an IP-based encapsulation for MPLS, called
MPLS-in-UDP (User Datagram Protocol) for situations where UDP MPLS-in-UDP (User Datagram Protocol) for situations where UDP
encapsulation is preferred to direct use of MPLS, e.g., to enable encapsulation is preferred to direct use of MPLS, e.g., to enable
UDP-based ECMP (Equal Cost Multi-Pathing) or link aggregation. MPLS- UDP-based ECMP (Equal Cost Multi-Pathing) or link aggregation. The
in-UDP is primarily applicable to service provider networks, and MPLS-in-UDP encapsulation technology must only be deployed within a
additional restrictions apply to MPLS-in-UDP usage for traffic that single network (with a single network operator) or networks of an
is not congestion controlled and to UDP zero checksum usage with adjacent set of co-operating network operators where traffic is
IPv6. managed to avoid congestion, rather than over the Internet where
congestion control is required. Usage restrictions apply to MPLS-in-
UDP usage for traffic that is not congestion controlled and to UDP
zero checksum usage with IPv6.
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 June 21, 2015. This Internet-Draft will expire on July 18, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Existing Encapsulations . . . . . . . . . . . . . . . . . 3 1.1. Existing Encapsulations . . . . . . . . . . . . . . . . . 3
1.2. Motivations for MPLS-in-UDP Encapsulation . . . . . . . . 3 1.2. Motivations for MPLS-in-UDP Encapsulation . . . . . . . . 3
1.3. Application Statements . . . . . . . . . . . . . . . . . 4 1.3. Applicability Statements . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Encapsulation in UDP . . . . . . . . . . . . . . . . . . . . 4 3. Encapsulation in UDP . . . . . . . . . . . . . . . . . . . . 4
3.1. UDP Checksum Usage with IPv6 . . . . . . . . . . . . . . 6 3.1. UDP Checksum Usage with IPv6 . . . . . . . . . . . . . . 6
3.2. Middlebox Considerations for IPv6 UDP Zero Checksums . . 9 3.2. Middlebox Considerations for IPv6 UDP Zero Checksums . . 9
4. Processing Procedures . . . . . . . . . . . . . . . . . . . . 9 4. Processing Procedures . . . . . . . . . . . . . . . . . . . . 9
5. Congestion Considerations . . . . . . . . . . . . . . . . . . 10 5. Congestion Considerations . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
This document specifies an IP-based encapsulation for MPLS, i.e. This document specifies an IP-based encapsulation for MPLS, i.e.
MPLS-in-UDP (User Datagram Protocol), which is applicable in some MPLS-in-UDP (User Datagram Protocol), which is applicable in some
circumstances where IP-based encapsulation for MPLS is required and circumstances where IP-based encapsulation for MPLS is required and
further fine-grained load balancing of MPLS packets over IP networks further fine-grained load balancing of MPLS packets over IP networks
over Equal Cost Multi-Path (ECMP) and/or Link Aggregation Groups over Equal Cost Multi-Path (ECMP) and/or Link Aggregation Groups
(LAG) is required as well. There are already IP-based encapsulations (LAG) is required as well. There are already IP-based encapsulations
for MPLS that allow for fine-grained load balancing by using some for MPLS that allow for fine-grained load balancing by using some
special field in the encapsulation header as an entropy field. special field in the encapsulation header as an entropy field.
However, MPLS-in-UDP can be advantageous since some networks have However, MPLS-in-UDP can be advantageous since networks have used the
used the UDP port number fields as a basis for load-balancing UDP port number fields as a basis for load-balancing solutions for
solutions for some time. This is similar to why LISP [RFC6830] uses some time.
UDP encapsulation.
Like other IP-based encapsulation methods for MPLS, this Like other IP-based encapsulation methods for MPLS, this
encapsulation allows for two Label Switching Routers (LSR) to be encapsulation allows for two Label Switching Routers (LSR) to be
adjacent on a Label Switched Path (LSP), while separated by an IP adjacent on a Label Switched Path (LSP), while separated by an IP
network. In order to support this encapsulation, each LSR needs to network. In order to support this encapsulation, each LSR needs to
know the capability to decapsulate MPLS-in-UDP by the remote LSRs. know the capability to decapsulate MPLS-in-UDP by the remote LSRs.
This specification defines only the data plane encapsulation and does This specification defines only the data plane encapsulation and does
not concern itself with how the knowledge to use this encapsulation not concern itself with how the knowledge to use this encapsulation
is conveyed. Specifically, this capability can be either manually is conveyed. Specifically, this capability can be either manually
configured on each LSR or be dynamically advertised in manners that configured on each LSR or be dynamically advertised in manners that
skipping to change at page 4, line 11 skipping to change at page 4, line 11
distributing IP traffic "microflows" [RFC2474] over ECMPs and/or LAG distributing IP traffic "microflows" [RFC2474] over ECMPs and/or LAG
based on the hash of the five-tuple of User Datagram Protocol (UDP) based on the hash of the five-tuple of User Datagram Protocol (UDP)
[RFC0768] and Transmission Control Protocol (TCP) packets (i.e., [RFC0768] and Transmission Control Protocol (TCP) packets (i.e.,
source IP address, destination IP address, source port, destination source IP address, destination IP address, source port, destination
port, and protocol). By encapsulating the MPLS packets into an UDP port, and protocol). By encapsulating the MPLS packets into an UDP
tunnel and using the source port of the UDP header as an entropy tunnel and using the source port of the UDP header as an entropy
field, the existing load-balancing capability as mentioned above can field, the existing load-balancing capability as mentioned above can
be leveraged to provide fine-grained load-balancing of MPLS traffic be leveraged to provide fine-grained load-balancing of MPLS traffic
over IP networks. over IP networks.
1.3. Application Statements 1.3. Applicability Statements
The MPLS-in-UDP encapsulation technology MUST only be deployed within The MPLS-in-UDP encapsulation technology MUST only be deployed within
a Service Provider (SP) network or networks of an adjacent set of co- a single network (with a single network operator) or networks of an
operating SPs where congestion control is not a concern, rather than adjacent set of co-operating network operators where traffic is
over the Internet where congestion control is required. Furthermore, managed to avoid congestion, rather than over the Internet where
packet filters SHOULD be added to prevent MPLS-in-UDP packets from congestion control is required. Furthermore, packet filters SHOULD
escaping from the service provider networks due to misconfiguation or be added to prevent MPLS-in-UDP packets from escaping from the
packet errors. network due to misconfiguation or packet errors.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Encapsulation in UDP 3. Encapsulation in UDP
MPLS-in-UDP encapsulation format is shown as follows: MPLS-in-UDP encapsulation format is shown as follows:
skipping to change at page 5, line 34 skipping to change at page 5, line 34
indicate that the UDP tunnel payload is an MPLS packet. indicate that the UDP tunnel payload is an MPLS packet.
UDP Length UDP Length
The usage of this field is in accordance with the current UDP The usage of this field is in accordance with the current UDP
specification [RFC0768]. specification [RFC0768].
UDP Checksum UDP Checksum
For IPv4 UDP encapsulation, this field is RECOMMENDED to be set For IPv4 UDP encapsulation, this field is RECOMMENDED to be set
to zero because the IPv4 header includes a checksum and use of to zero for performance or implementation reasons because the
the UDP checksum is optional with IPv4, unless checksum IPv4 header includes a checksum and use of the UDP checksum is
protection of VPN labels is important (See Section 6). For optional with IPv4, unless checksum protection of VPN labels is
IPv6 UDP encapsulation, the IPv6 header does not include a important (See Section 6). For IPv6 UDP encapsulation, the
checksum, so this field MUST contain a UDP checksum that MUST IPv6 header does not include a checksum, so this field MUST
be used as specified in [RFC0768] and [RFC2460] unless one of contain a UDP checksum that MUST be used as specified in
the exceptions that allows use of UDP zero-checksum mode (as [RFC0768] and [RFC2460] unless one of the exceptions that
specified in [RFC6935]) applies. See Section 3.1 for allows use of UDP zero-checksum mode (as specified in
specification of these exceptions and additional requirements [RFC6935]) applies. See Section 3.1 for specification of these
that apply when UDP zero-checksum mode is used for MPLS-in-UDP exceptions and additional requirements that apply when UDP
traffic over IPv6. zero-checksum mode is used for MPLS-in-UDP traffic over IPv6.
MPLS Label Stack MPLS Label Stack
This field contains an MPLS Label Stack as defined in This field contains an MPLS Label Stack as defined in
[RFC3032]. [RFC3032].
Message Body Message Body
This field contains one MPLS message body. This field contains one MPLS message body.
3.1. UDP Checksum Usage with IPv6 3.1. UDP Checksum Usage with IPv6
skipping to change at page 6, line 25 skipping to change at page 6, line 25
Section 3.1 of [RFC6936]: Section 3.1 of [RFC6936]:
"There is extensive experience with deployments using tunnel "There is extensive experience with deployments using tunnel
protocols in well-managed networks (e.g., corporate networks and protocols in well-managed networks (e.g., corporate networks and
service provider core networks). This has shown the robustness of service provider core networks). This has shown the robustness of
methods such as Pseudowire Emulation Edge-to-Edge (PWE3) and MPLS methods such as Pseudowire Emulation Edge-to-Edge (PWE3) and MPLS
that do not employ a transport protocol checksum and that have not that do not employ a transport protocol checksum and that have not
specified mechanisms to protect from corruption of the unprotected specified mechanisms to protect from corruption of the unprotected
headers(such as the VPN Identifier in MPLS)". headers(such as the VPN Identifier in MPLS)".
This document focuses on service provider core networks. The UDP The UDP checksum MUST be implemented and MUST be used in accordance
checksum MUST be implemented and MUST be used in accordance with with [RFC0768] and [RFC2460] for MPLS-in-UDP traffic over IPv6 unless
[RFC0768] and [RFC2460] for MPLS-in-UDP traffic over IPv6 unless one one or more of the following exceptions applies and the additional
or more of the following exceptions applies and the additional
requirements stated below are also complied with. There are three requirements stated below are also complied with. There are three
exceptions that allow use of UDP zero-checksum mode for IPv6 with exceptions that allow use of UDP zero-checksum mode for IPv6 with
MPLS-in-UDP, subject to the additional requirements stated below in MPLS-in-UDP, subject to the additional requirements stated below in
this section. The three exceptions are: this section. The three exceptions are:
a. Use of MPLS-in-UDP in networks under single administrative a. Use of MPLS-in-UDP in networks under single administrative
control (such as within a single service provider) where it is control (such as within a single operator's network) where it is
known (perhaps through knowledge of equipment types and lower known (perhaps through knowledge of equipment types and lower
layer checks) that packet corruption is exceptionally unlikely layer checks) that packet corruption is exceptionally unlikely
and where the operator is willing to take the risk of undetected and where the operator is willing to take the risk of undetected
packet corruption. packet corruption.
b. Use of MPLS-in-UDP in networks under single administrative b. Use of MPLS-in-UDP in networks under single administrative
control (such as within a single service provider) where it is control (such as within a single operator's network) where it is
judged through observational measurements (perhaps of historic or judged through observational measurements (perhaps of historic or
current traffic flows that use a non-zero checksum) that the current traffic flows that use a non-zero checksum) that the
level of packet corruption is tolerably low and where the level of packet corruption is tolerably low and where the
operator is willing to take the risk of undetected packet operator is willing to take the risk of undetected packet
corruption. corruption.
c. Use of MPLS-in-UDP for traffic delivery for applications that are c. Use of MPLS-in-UDP for traffic delivery for applications that are
tolerant of misdelivered or corrupted packets (perhaps through tolerant of misdelivered or corrupted packets (perhaps through
higher layer checksum, validation, and retransmission or higher layer checksum, validation, and retransmission or
transmission redundancy) where the operator is willing to rely on transmission redundancy) where the operator is willing to rely on
the applications using the tunnel to survive any corrupt packets. the applications using the tunnel to survive any corrupt packets.
These exceptions may also be extended to the use of MPLS-in-UDP These exceptions may also be extended to the use of MPLS-in-UDP
within a set of closely cooperating network administrations (such as within a set of closely cooperating network administrations (such as
service providers who have agreed to work together in order to network operators who have agreed to work together in order to
jointly provide specific services). Even when one of the above jointly provide specific services). Even when one of the above
exceptions applies, use of UDP checksums may be appropriate when VPN exceptions applies, use of UDP checksums may be appropriate when VPN
services are provided over MPLS-in-UDP, see Section 6. services are provided over MPLS-in-UDP, see Section 6.
As such, for IPv6, the UDP checksum for MPLS-in-UDP MUST be used as As such, for IPv6, the UDP checksum for MPLS-in-UDP MUST be used as
specified in [RFC0768] and [RFC2460] over the general Internet, and specified in [RFC0768] and [RFC2460] for tunnels that span multiple
for tunnels that span multiple networks whose network administrations networks whose network administrations do not cooperate closely, even
do not cooperate closely, even if each non-cooperating network if each non-cooperating network administration independently
administration independently satisfies one or more of the exceptions satisfies one or more of the exceptions for UDP zero-checksum mode
for UDP zero-checksum mode usage with MPLS-in-UDP over IPv6. usage with MPLS-in-UDP over IPv6.
The following additional requirements apply to implementation and use The following additional requirements apply to implementation and use
of UDP zero-checksum mode for MPLS-in-UDP over IPv6: of UDP zero-checksum mode for MPLS-in-UDP over IPv6:
a. Use of the UDP checksum with IPv6 MUST be the default a. Use of the UDP checksum with IPv6 MUST be the default
configuration of all MPLS-in-UDP implementations. configuration of all MPLS-in-UDP implementations.
b. An MPLS-in-UDP implementation MUST comply with all requirements b. An MPLS-in-UDP implementation MUST comply with all requirements
specified in Section 4 of [RFC6936] and with requirement 1 specified in Section 4 of [RFC6936] and with requirement 1
specified in Section 5 of [RFC6936]. specified in Section 5 of [RFC6936].
c. An MPLS-in-UDP receiver node SHOULD only allow the use of UDP c. An MPLS-in-UDP receiver node SHOULD only allow the use of UDP
zero-checksum mode for IPv6 on a single UDP port regardless of zero-checksum mode for IPv6 on a single received UDP Destination
sender. The motivation for this requirement is possible Port regardless of the sender. The motivation for this
corruption of the UDP destination port, which may cause packet requirement is possible corruption of the UDP destination port,
delivery to the wrong UDP port. If that other UDP port requires which may cause packet delivery to the wrong UDP port. If that
the UDP checksum, the misdelivered packet will be discarded other UDP port requires the UDP checksum, the misdelivered packet
will be discarded
d. An MPLS-in-UDP receiver MUST check that the source and d. An MPLS-in-UDP receiver MUST check that the source and
destination IPv6 addresses are valid for the MPLS-in-UDP tunnel destination IPv6 addresses are valid for the MPLS-in-UDP tunnel
on which the packet was received if that tunnel uses UDP zero- on which the packet was received if that tunnel uses UDP zero-
checksum mode and discard any packet for which this check fails. checksum mode and discard any packet for which this check fails.
e. An MPLS-in-UDP sender SHOULD use different IPv6 addresses for e. An MPLS-in-UDP sender SHOULD use different IPv6 addresses for
each MPLS-in-UDP tunnel that uses UDP zero-checksum mode each MPLS-in-UDP tunnel that uses UDP zero-checksum mode
regardless of receiver in order to strengthen the receiver's regardless of receiver in order to strengthen the receiver's
check of the IPv6 source address. When this is not possible, it check of the IPv6 source address. When this is not possible, it
is RECOMMENDED to use each source IPv6 address for as few UDP is RECOMMENDED to use each source IPv6 address for as few UDP
zero-checksum mode MPLS-in-UDP tunnels as is feasible. zero-checksum mode MPLS-in-UDP tunnels as is feasible.
f. An MPLS-in-UDP receiver MUST check that the top label of the MPLS f. Any middlebox support for MPLS-in-UDP with UDP zero-checksum mode
label stack is valid for the tunnel on which the packet was
received if that tunnel uses UDP zero-checksum mode and discard
any packet for which this check fails. This check will often be
part of the MPLS LSR forwarding logic, but MUST be scoped to the
specific tunnel.
g. Any middlebox support for MPLS-in-UDP with UDP zero-checksum mode
for IPv6 MUST comply with requirements 1 and 8-10 in Section 5 of for IPv6 MUST comply with requirements 1 and 8-10 in Section 5 of
[RFC6936]. [RFC6936].[RFC6936].
h. Measures SHOULD be taken to prevent IPv6 traffic with zero UDP g. Measures SHOULD be taken to prevent IPv6 traffic with zero UDP
checksums from "escaping" to the general Internet; see Section 5 checksums from "escaping" to the general Internet; see Section 5
for examples of such measures. for examples of such measures.
i. IPv6 traffic with zero UDP checksums MUST be actively monitored h. IPv6 traffic with zero UDP checksums MUST be actively monitored
for errors by the network operator. for errors by the network operator.
The above requirements do not change either the requirements The above requirements do not change either the requirements
specified in [RFC2460] as modified by [RFC6935] or the requirements specified in [RFC2460] as modified by [RFC6935] or the requirements
specified in [RFC6936]. specified in [RFC6936].
The requirements to check the source IPv6 address and top label of The requirement to check the source IPv6 address in addition to the
the MPLS stack (in addition to the destination IPv6 address), plus destination IPv6 address, plus the strong recommendation against
the strong recommendation against reuse of source IPv6 addresses reuse of source IPv6 addresses among MPLS-in-UDP tunnels collectively
among MPLS-in-UDP tunnels collectively provide some mitigation for provide some mitigation for the absence of UDP checksum coverage of
the absence of UDP checksum coverage of the IPv6 header. The the IPv6 header. In addition, the MPLS data plane only forwards
expected result for IPv6 UDP zero-checksum mode for MPLS-in-UDP is packets with valid labels (i.e., labels that have been distributed by
that corruption of the destination IPv6 address will usually cause the tunnel egress LSR), providing some additional opportunity to
packet discard, as offsetting corruptions to the source IPv6 and/or detect MPLS-in-UDP packet misdelivery when the misdelivered packet
MPLS top label are unlikely. Additional assurance is provided by the contains a label that is not valid for forwarding at the receiving
restrictions in the above exceptions that limit usage of IPv6 UDP LSR. The expected result for IPv6 UDP zero-checksum mode for MPLS-
zero-checksum mode to well-managed networks for which MPLS packet in-UDP is that corruption of the destination IPv6 address will
corruption has not been a problem in practice. usually cause packet discard, as offsetting corruptions to the source
IPv6 and/or MPLS top label are unlikely. Additional assurance is
provided by the restrictions in the above exceptions that limit usage
of IPv6 UDP zero-checksum mode to well-managed networks for which
MPLS packet corruption has not been a problem in practice.
Hence MPLS-in-UDP is suitable for transmission over lower layers in Hence MPLS-in-UDP is suitable for transmission over lower layers in
the well-managed networks that are allowed by the exceptions stated the well-managed networks that are allowed by the exceptions stated
above and the rate of corruption of the inner IP packet on such above and the rate of corruption of the inner IP packet on such
networks is not expected to increase by comparison to MPLS traffic networks is not expected to increase by comparison to MPLS traffic
that is not encapsulated in UDP. For these reasons, MPLS-in-UDP does that is not encapsulated in UDP. For these reasons, MPLS-in-UDP does
not provide an additional integrity check when UDP zero-checksum mode not provide an additional integrity check when UDP zero-checksum mode
is used with IPv6, and this design is in accordance with requirements is used with IPv6, and this design is in accordance with requirements
2, 3 and 5 specified in Section 5 of [RFC6936]. 2, 3 and 5 specified in Section 5 of [RFC6936].
skipping to change at page 11, line 10 skipping to change at page 11, line 10
controlled, i.e., it is assumed that the transport protocols controlled, i.e., it is assumed that the transport protocols
generating IP-based traffic at the sender already employ generating IP-based traffic at the sender already employ
mechanisms that are sufficient to address congestion on the path. mechanisms that are sufficient to address congestion on the path.
Consequently, a tunnel carrying IP-based traffic should already Consequently, a tunnel carrying IP-based traffic should already
interact appropriately with other traffic sharing the path, and interact appropriately with other traffic sharing the path, and
specific congestion control mechanisms for the tunnel are not specific congestion control mechanisms for the tunnel are not
necessary". necessary".
For this reason, where MPLS-in-UDP tunneling is used to carry IP For this reason, where MPLS-in-UDP tunneling is used to carry IP
traffic that is known to be congestion controlled, the UDP tunnels traffic that is known to be congestion controlled, the UDP tunnels
MAY be used across any combination of a single service provider, MAY be used within a single network or across multiple networks, with
multiple cooperating service providers, or across the general cooperating network operators. Internet IP traffic is generally
Internet. Internet IP traffic is generally assumed to be congestion- assumed to be congestion-controlled. Similarly, in general Layer 3
controlled. Similarly, in general Layer 3 VPNs are carrying IP VPNs are carrying IP traffic that is similarly assumed to be
traffic that is similarly assumed to be congestion controlled. congestion controlled.
Whether or not Layer 2 VPN traffic is congestion controlled may Whether or not Layer 2 VPN traffic is congestion controlled may
depend upon the specific services being offered and what use is being depend upon the specific services being offered and what use is being
made of the layer 2 services. made of the layer 2 services.
However, MPLS is also used in many cases to carry traffic that is not However, MPLS is also used in many cases to carry traffic that is not
necessarily congestion controlled. For example, MPLS may be used to necessarily congestion controlled. For example, MPLS may be used to
carry pseudowire or VPN traffic where specific bandwidth guarantees carry pseudowire or VPN traffic where specific bandwidth guarantees
are provided to each pseudowire, or to each VPN. are provided to each pseudowire, or to each VPN.
In such cases service providers may avoid congestion by careful In such cases network operators may avoid congestion by careful
provisioning of their networks, by rate limiting of user data provisioning of their networks, by rate limiting of user data
traffic, and/or by using MPLS Traffic Engineering (MPLS-TE) to assign traffic, and/or by using MPLS Traffic Engineering (MPLS-TE) to assign
specific bandwidth guarantees to each LSP. Where MPLS is carried specific bandwidth guarantees to each LSP. Where MPLS is carried
over UDP over IP, the identity of each individual MPLS flow is in over UDP over IP, the identity of each individual MPLS flow is in
general lost and MPLS-TE cannot be used to guarantee bandwidth to general lost and MPLS-TE cannot be used to guarantee bandwidth to
specific flows (since many LSPs may be multiplexed over a single UDP specific flows (since many LSPs may be multiplexed over a single UDP
tunnel, and many UDP tunnels may be mixed in an IP network). tunnel, and many UDP tunnels may be mixed in an IP network).
For this reason, where the MPLS traffic is not congestion controlled, For this reason, where the MPLS traffic is not congestion controlled,
MPLS-in-UDP tunnels MUST only be used within a single service MPLS-in-UDP tunnels MUST only be used within a single operator's
provider that utilizes careful provisioning (e.g., rate limiting at network that utilizes careful provisioning (e.g., rate limiting at
the entries of the network while over-provisioning network capacity) the entries of the network while over-provisioning network capacity)
to ensure against congestion, or within a limited number of service to ensure against congestion, or within a limited number of networks
providers who closely cooperate in order to jointly provide this same whose operators closely cooperate in order to jointly provide this
careful provisioning. same careful provisioning.
As such, MPLS-in-UDP MUST NOT be used over the general Internet, or As such, MPLS-in-UDP MUST NOT be used over the general Internet, or
over non-cooperating SPs, to carry traffic that is not congestion- over non-cooperating network operators, to carry traffic that is not
controlled. congestion-controlled.
Measures SHOULD be taken to prevent non-congestion-controlled MPLS- Measures SHOULD be taken to prevent non-congestion-controlled MPLS-
in-UDP traffic from "escaping" to the general Internet, e.g.: in-UDP traffic from "escaping" to the general Internet, e.g.:
a. Physical or logical isolation of the links carrying MPLS-over-UDP a. Physical or logical isolation of the links carrying MPLS-over-UDP
from the general Internet. from the general Internet.
b. Deployment of packet filters that block the UDP ports assigned b. Deployment of packet filters that block the UDP Destination Ports
for MPLS-over-UDP. used for MPLS-over-UDP.
c. Imposition of restrictions on MPLS-in-UDP traffic by software c. Imposition of restrictions on MPLS-in-UDP traffic by software
tools used to set up MPLS-in-UDP tunnels between specific end tools used to set up MPLS-in-UDP tunnels between specific end
systems (as might be used within a single data center). systems (as might be used within a single data center).
d. Use of a "Managed Circuit Breaker" for the MPLS traffic as d. Use of a "Managed Circuit Breaker" for the MPLS traffic as
described in [I-D.ietf-tsvwg-circuit-breaker]. described in [I-D.ietf-tsvwg-circuit-breaker].
6. Security Considerations 6. Security Considerations
skipping to change at page 13, line 27 skipping to change at page 13, line 27
When that is the case, UDP checksums SHOULD be used for MPLS-in-UDP When that is the case, UDP checksums SHOULD be used for MPLS-in-UDP
with both IPv4 and IPv6, and in particular, UDP zero-checksum mode with both IPv4 and IPv6, and in particular, UDP zero-checksum mode
SHOULD NOT be used with IPv6. Each UDP checksum covers the VPN SHOULD NOT be used with IPv6. Each UDP checksum covers the VPN
label, thereby providing increased assurance of isolation among VPNs. label, thereby providing increased assurance of isolation among VPNs.
7. IANA Considerations 7. IANA Considerations
One UDP destination port number indicating MPLS needs to be allocated One UDP destination port number indicating MPLS needs to be allocated
by IANA: by IANA:
Service Name: MPLS-in-UDP Service Name: MPLS-UDP
Transport Protocol(s): UDP Transport Protocol(s): UDP
Assignee: IESG <iesg@ietf.org> Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>. Contact: IETF Chair <chair@ietf.org>.
Description: Encapsulate MPLS packets in UDP tunnels. Description: Encapsulate MPLS packets in UDP tunnels.
Reference: This document -- draft-ietf-mpls-in-udp (MPLS WG Reference: This document -- draft-ietf-mpls-in-udp (MPLS WG
document). document).
Port Number: TBD1 -- To be assigned by IANA. Port Number: TBD1 -- To be assigned by IANA.
One UDP destination port number indicating MPLS with DTLS needs to be One UDP destination port number indicating MPLS with DTLS needs to be
allocated by IANA: allocated by IANA:
Service Name: MPLS-in-UDP-with-DTLS Service Name: MPLS-UDP-DTLS
Transport Protocol(s): UDP Transport Protocol(s): UDP
Assignee: IESG <iesg@ietf.org> Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>. Contact: IETF Chair <chair@ietf.org>.
Description: Encapsulate MPLS packets in UDP tunnels with DTLS. Description: Encapsulate MPLS packets in UDP tunnels with DTLS.
Reference: This document -- draft-ietf-mpls-in-udp (MPLS WG Reference: This document -- draft-ietf-mpls-in-udp (MPLS WG
skipping to change at page 16, line 45 skipping to change at page 16, line 45
J. Young, "Encapsulation of MPLS over Layer 2 Tunneling J. Young, "Encapsulation of MPLS over Layer 2 Tunneling
Protocol Version 3", RFC 4817, March 2007. Protocol Version 3", RFC 4817, March 2007.
[RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load- [RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load-
Balancing for Mesh Softwires", RFC 5640, August 2009. Balancing for Mesh Softwires", RFC 5640, August 2009.
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
for Equal Cost Multipath Routing and Link Aggregation in for Equal Cost Multipath Routing and Link Aggregation in
Tunnels", RFC 6438, November 2011. Tunnels", RFC 6438, November 2011.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830, January
2013.
Authors' Addresses Authors' Addresses
Xiaohu Xu Xiaohu Xu
Huawei Technologies Huawei Technologies
No.156 Beiqing Rd No.156 Beiqing Rd
Beijing 100095 Beijing 100095
CHINA CHINA
Phone: +86-10-60610041 Phone: +86-10-60610041
Email: xuxiaohu@huawei.com Email: xuxiaohu@huawei.com
Nischal Sheth Nischal Sheth
 End of changes. 33 change blocks. 
96 lines changed or deleted 90 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/