Internet DRAFT - draft-kumar-softwire-uet
draft-kumar-softwire-uet
softwire C. Pignataro
Internet-Draft N. Kumar
Intended status: Standards Track P. Mohapatra
Expires: August 22, 2013 C. Filsfils
Cisco Systems, Inc.
February 18, 2013
UDP Entropy Tunnel for Softwire
draft-kumar-softwire-uet-00
Abstract
This document describes a method for encapsulatation of tunneled
packets within UDP in order to provide per-flow entropy for load-
balancing. The method is targeted for use with softwire mesh
deployments that include routers which have support for load-
balancing based on UDP ports and not fields in L2TPv3 or GRE.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 22, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Pignataro, et al. Expires August 22, 2013 [Page 1]
Internet-Draft UET-Softwire February 2013
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3
3. UDP Entropy Tunnel Encapsulation . . . . . . . . . . . . . . . 3
4. Procedure to use UDP Entropy Tunnel Encapsulation . . . . . . . 4
4.1. Ingress node procedure . . . . . . . . . . . . . . . . . . 5
4.2. Egress node procedure . . . . . . . . . . . . . . . . . . . 5
5. Entropy ID Sub-TLV . . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Pignataro, et al. Expires August 22, 2013 [Page 2]
Internet-Draft UET-Softwire February 2013
1. Introduction
[RFC5565] explains how routing information in BGP and data packets in
L2TPv3 or GRE are tunneled from one edge of an IPv4 network, over
IPv6, to another IPv4 network or from one edge of an IPv6 network,
over IPv4, to another IPv6 network. [RFC5640] describes how to
encode and load-balance specific flows by utilizing the L2TPv3
Session ID or GRE Key field. While implementations and deployments
exist, not as many routers support the per-hop behavior described in
[RFC5640] compared to routers that support load-balancing based on
UDP ports.
In cases where [RFC5640] is not supported on the intervening network
where tunneled packets traverse and where load-balancing is
desirable, UDP may be used in order to encode additional entropy for
routers to perform more granular load-balancing. In addition to
entropy information for more granular load-balancing, use of the "UDP
Entropy Tunnel" encapsulation defined in this document allows egress
devices to identify additional information about the type of softwire
packet being carried.
UET encapsulation defined in this document appends Entropy ID
assigned and advertised by tunnel tailend node to Protocol ID and
encode the same as Destination port of UDP while using the source
port field to carry Entropy value. Each edge node is expected to
assign a minimum of one Entropy ID which makes the ingress node to
maintain one Entropy ID per egress node.
This document does not aim to deprecate or replace [RFC5640], but to
provide an alternative when there is no specific support for load-
balancing based on L2TPv3, GRE, or other softwire encapsulation
types.
2. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. UDP Entropy Tunnel Encapsulation
This section defines the UDP Entropy Tunnel encapsulation format as
below:
Pignataro, et al. Expires August 22, 2013 [Page 3]
Internet-Draft UET-Softwire February 2013
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port (entropy value) | E-ID | P-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Softwire Tunnel (Variable) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source Port
Resulting Entropy value (using any hashing algorithm)
is populated in this field.
E-ID
Entropy Identifier, used to identify UDP Entropy
Tunnel.
P-ID
Protocol Identifier, used to identify the softwire
service.
UDP Length
As defined in [RFC0768]
UDP Checksum
Set to zero.
4. Procedure to use UDP Entropy Tunnel Encapsulation
Below is a sample toplogy where softwire tunnel is used to deliver
payload between Client network,
+--------+ +--------+ +--------+ +--------+
| Client | | Ingress| _ _ _ _ _ | Egress | | Client |
| Network|====| Node |()_ _ _ _ _()| Node |====| Network|
+--------+ +--------+ softwire +--------+ +--------+
Pignataro, et al. Expires August 22, 2013 [Page 4]
Internet-Draft UET-Softwire February 2013
4.1. Ingress node procedure
Any Ingress node on sending traffic through softwire tunnel and if no
Entropy ID is received from remote endpoint via BGP or other
encapsulation signaling protocol, MUST NOT use UDP Entropy tunnel.
Any Ingress node on sending traffic through softwire tunnel and if an
Entropy ID is received from remote endpoint via BGP or other
encapsulation signaling protocol, MUST encapsulate with UDP Entropy
tunnel as below:
o Generate Entropy value using any hashing algorithm and populate
the Source port with the value.
o Copy the "Entropy ID" value received from remote endpoint to E-ID
field.
o Populate the P-ID field with Softwire encapsulation protocol (e.g,
L2TPv3, GRE-in-IP, IP-in-IP etc.)
o Set the UDP checksum value as zero as described in
[I-D.ietf-6man-udpchecksums] and [I-D.ietf-6man-udpzero].
The Ingress node further adds IP header to the above encapsulated UDP
based UDP Entropy tunnel header and send across the core to egress
node.
4.2. Egress node procedure
When any node is enabled with UDP based entropy, it assigns a locally
significant 8 bits Entropy ID. While any signaling protocol can be
used to advertise this assigned Entropy ID to other nodes, Section 5
of this document describes one mechanism using Tunnel Encapsulation
Attribute [RFC5512].
At the egress node, if the E-ID (See Section 3) of the UDP packet
matches locally assigned Entropy ID, MUST use P-ID field (See Section
3) to identify the Softwire encapsulation protocol.
When any node receives UDP Entropy Tunnel encapsulated packet and if
P-ID field doesnt match any of the locally configured softwire
service MUST drop the packet.
When any node receives traffic over softwire tunnel without UDP
Entropy Tunnel encapsulation MUST decapsulate the softwire
encapsulation and process the packet further.
Pignataro, et al. Expires August 22, 2013 [Page 5]
Internet-Draft UET-Softwire February 2013
5. Entropy ID Sub-TLV
Any node that is enabled with UDP based entropy, MUST inlcude Entropy
ID Sub-TLV (Type = 6) in Tunnel Encapsulation Attribute [RFC5512].
This Sub-TLV is of 4 octets length and can be used with any Tunnel
type proposed in [RFC5512] or any new tunnel type proposed in future.
The Entropy ID carried in this Sub-TLV is a 1 octet value and is
locally significant to the assigning edge node. While it is a local
matter, this document recommends to assign a single Entropy ID for
all Softwire transport enabled and advertise the same with all tunnel
type. Considering the number of available softwire transport
options, 8 bit of Entropy ID is sufficient to handle single Entropy
ID for all softwire transport or Entropy ID per softwire transport
implementations.
This document also strongly recommends to continue advertise Load-
balancing Block Sub-TLV [RFC5640] along with Entropy ID Sub-TLV. If
an ingress node does not support Entropy ID Sub-TLV, softwire load
balancing for L2TPv3-over-IP or GRE can be acheived by procedure
specified in [RFC5640].
The encoding of the Sub-TLV is as below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Entropy ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
Reserved for future use.
Entropy ID
Entropy Identifier, used to identify UDP Entropy
Tunnel.
6. IANA Considerations
IANA is requested to assign Sub-TLV type = 6 for Entropy-ID Sub-TLV,
in the BGP Tunnel Encapsulation Attribute Sub-TLVs registry.
7. Security Considerations
Same security considerations described in [RFC5512], [RFC5640], and
[I-D.ietf-6man-udpchecksums] are applicable.
Pignataro, et al. Expires August 22, 2013 [Page 6]
Internet-Draft UET-Softwire February 2013
8. Acknowledgement
The authors would like to thank Mark Townsley for his review and
comments.
9. References
9.1. Normative References
[I-D.ietf-6man-udpchecksums]
Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and
UDP Checksums for Tunneled Packets",
draft-ietf-6man-udpchecksums-07 (work in progress),
January 2013.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation
Subsequent Address Family Identifier (SAFI) and the BGP
Tunnel Encapsulation Attribute", RFC 5512, April 2009.
[RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
Framework", RFC 5565, June 2009.
[RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load-
Balancing for Mesh Softwires", RFC 5640, August 2009.
9.2. Informative References
[I-D.ietf-6man-udpzero]
Fairhurst, G. and M. Westerlund, "Applicability Statement
for the use of IPv6 UDP Datagrams with Zero Checksums",
draft-ietf-6man-udpzero-10 (work in progress),
January 2013.
Pignataro, et al. Expires August 22, 2013 [Page 7]
Internet-Draft UET-Softwire February 2013
Authors' Addresses
Carlos Pignataro
Cisco Systems, Inc.
7200 Kit Creek Road
Research Triangle Park, NC 27709-4987
US
Email: cpignata@cisco.com
Nagendra Kumar
Cisco Systems, Inc.
Cessna Business Park, Outer Ring Road
Bangalore, KARNATAKA 560108
INDIA
Email: naikumar@cisco.com
Pradosh Mohapatra
Cisco Systems, Inc.
170 Tasman Drive
San Jose, CA 95134
US
Email: pmohapat@cisco.com
Clarence Filsfils
Cisco Systems, Inc.
Brussels 1000
BELGIUM
Email: cfilsfil@cisco.com
Pignataro, et al. Expires August 22, 2013 [Page 8]
