One document matched: draft-kumar-softwire-uet-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category='std' ipr='trust200902' docName='draft-kumar-softwire-uet-00'>
<front>
<title abbrev="UET-Softwire">UDP Entropy Tunnel for Softwire</title>
<author initials="C." surname="Pignataro" fullname="Carlos Pignataro">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>7200 Kit Creek Road</street>
<city>Research Triangle Park</city> <region>NC</region> <code>27709-4987</code>
<country>US</country>
</postal>
<email>cpignata@cisco.com</email>
</address>
</author>
<author initials="N." surname="Kumar" fullname="Nagendra Kumar">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Cessna Business Park, Outer Ring Road</street>
<city>Bangalore</city> <region>KARNATAKA</region> <code>560108</code>
<country>INDIA</country>
</postal>
<email>naikumar@cisco.com</email>
</address>
</author>
<author initials="P." surname="Mohapatra" fullname="Pradosh Mohapatra">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 Tasman Drive</street>
<city>San Jose</city> <region>CA</region> <code>95134</code>
<country>US</country>
</postal>
<email>pmohapat@cisco.com</email>
</address>
</author>
<author initials="C." surname="Filsfils" fullname="Clarence Filsfils">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street></street>
<city></city> <region>Brussels</region> <code>1000</code>
<country>BELGIUM</country>
</postal>
<email>cfilsfil@cisco.com</email>
</address>
</author>
<date day="18" month="February" year="2013" />
<area>Internet</area>
<workgroup>softwire</workgroup>
<keyword>softwire</keyword>
<keyword>Load balancing</keyword>
<abstract><t>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.</t></abstract>
</front>
<middle>
<section title="Introduction">
<t><xref target="RFC5565"></xref> 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. <xref target="RFC5640"></xref> 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
<xref target="RFC5640"></xref> compared to routers that support
load-balancing based on UDP ports.</t>
<t> In cases where <xref target="RFC5640"></xref> 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. </t>
<t> 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.</t>
<t> This document does not aim to deprecate or replace <xref
target="RFC5640"></xref>, but to provide an alternative when there
is no specific support for load-balancing based on L2TPv3, GRE, or
other softwire encapsulation types. </t>
</section>
<section title="Requirements notation">
<t>
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 <xref target="RFC2119"/>.
</t>
</section>
<section title="UDP Entropy Tunnel Encapsulation">
<t>This section defines the UDP Entropy Tunnel encapsulation format as below:
</t><figure>
<artwork><![CDATA[
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.
]]></artwork>
</figure><t></t>
</section>
<section title="Procedure to use UDP Entropy Tunnel Encapsulation">
<t> Below is a sample toplogy where softwire tunnel is used to deliver
payload between Client network,
</t><figure>
<artwork><![CDATA[
+--------+ +--------+ +--------+ +--------+
| Client | | Ingress| _ _ _ _ _ | Egress | | Client |
| Network|====| Node |()_ _ _ _ _()| Node |====| Network|
+--------+ +--------+ softwire +--------+ +--------+
]]></artwork>
</figure><t></t>
<section title="Ingress node procedure">
<t>
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.
</t>
<t>
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:
<list style="symbols">
<t>Generate Entropy value using any hashing algorithm and populate the Source port with the value.</t>
<t>Copy the "Entropy ID" value received from remote endpoint to E-ID field.</t>
<t>Populate the P-ID field with Softwire encapsulation protocol (e.g, L2TPv3, GRE-in-IP, IP-in-IP etc.)</t>
<t> Set the UDP checksum value as zero as described in
<xref target="I-D.ietf-6man-udpchecksums"></xref> and <xref target="I-D.ietf-6man-udpzero"></xref>.</t>
</list></t>
<t>
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.
</t>
</section>
<section title="Egress node procedure">
<t>
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 <xref target ="RFC5512"></xref>.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t> When any node receives traffic over softwire tunnel without UDP Entropy Tunnel encapsulation MUST
decapsulate the softwire encapsulation and process the packet further.</t>
</section>
</section>
<section title="Entropy ID Sub-TLV">
<t>Any node that is enabled with UDP based entropy, MUST inlcude Entropy ID Sub-TLV (Type = 6) in Tunnel Encapsulation
Attribute <xref target="RFC5512"></xref>. This Sub-TLV is of 4 octets length and can be used with any Tunnel type proposed in
<xref target="RFC5512"></xref> or any new tunnel type proposed in future.</t>
<t>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.</t>
<t>This document also strongly recommends to continue advertise Load-balancing Block Sub-TLV <xref target="RFC5640"></xref> 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 <xref target="RFC5640"></xref>.</t>
<t>The encoding of the Sub-TLV is as below:
</t><figure>
<artwork><![CDATA[
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.
]]></artwork>
</figure><t>
</t>
</section>
<section title="IANA Considerations">
<t>IANA is requested to assign Sub-TLV type = 6 for Entropy-ID Sub-TLV, in the BGP Tunnel Encapsulation Attribute Sub-TLVs registry.</t>
</section>
<section title="Security Considerations">
<t>Same security considerations described in <xref target="RFC5512"></xref>,
<xref target="RFC5640"></xref>, and
<xref target="I-D.ietf-6man-udpchecksums"></xref> are applicable.</t>
</section>
<section title="Acknowledgement">
<t> The authors would like to thank Mark Townsley for his review and comments.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.5640"?>
<?rfc include="reference.RFC.0768"?>
<?rfc include="reference.RFC.5512"?>
<?rfc include="reference.RFC.5565"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-6man-udpchecksums-07.xml"?>
</references>
<references title="Informative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-6man-udpzero-10.xml"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:06:18 |