One document matched: draft-tsou-softwire-bfd-ds-lite-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC0792 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0792.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4443 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4443.xml">
<!ENTITY RFC5880 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5880.xml">
<!ENTITY RFC5881 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5881.xml">
<!ENTITY RFC5882 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5882.xml">
<!ENTITY RFC5883 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5883.xml">
<!ENTITY RFC6333 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6333.xml">
<!ENTITY RFC6334 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6334.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-tsou-softwire-bfd-ds-lite-04" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the full title is longer than 39 characters -->
<title>DS-Lite Failure Detection and Failover</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Tina Tsou" initials="T." role="editor"
surname="Tsou">
<organization>Huawei Technologies (USA)</organization>
<address>
<postal>
<street>2330 Central Expressway</street>
<city>Santa Clara</city>
<code>CA 95050</code>
<country>USA</country>
</postal>
<phone>+1 408 330 4424</phone>
<email>tina.tsou.zouting@huawei.com</email>
</address>
</author>
<author fullname="Brandon Li" initials="B." surname="Li">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>M6, No. 156, Beiqing Road, Haidian District</street>
<city>Beijing</city>
<code>100094</code>
<country>China</country>
</postal>
<phone></phone>
<email>brandon.lijian@huawei.com</email>
</address>
</author>
<author fullname="Cathy Zhou" initials="C." surname="Zhou">
<organization>Huawei Technologies </organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<country>China</country>
</postal>
<phone></phone>
<email>cathy.zhou@huawei.com</email>
</address>
</author>
<author fullname="Juergen Schoenwaelder" initials="J." surname="Schoenwaelder">
<organization>Jacobs University Bremen</organization>
<address>
<postal>
<street>Campus Ring 1</street>
<city>Bremen</city>
<code>28759</code>
<country>Germany</country>
</postal>
<phone></phone>
<email>j.schoenwaelder@jacobs-university.de</email>
</address>
</author>
<author fullname="Reinaldo Penno" initials="R." surname="Penno">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drivee</street>
<city>San Jose, California</city>
<code>95134</code>
<country>USA</country>
</postal>
<phone></phone>
<email>repenno@cisco.com</email>
</address>
</author>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street>Rennes,35000</street>
<city></city>
<code></code>
<country>France</country>
</postal>
<phone></phone>
<email>mohamed.boucadair@orange.com</email>
</address>
</author>
<date year="2013" />
<!-- Meta-data Declarations -->
<area>INT</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<abstract>
<t>
In DS-Lite, the tunnel is stateless, not associated with any
state information, and no failure detection and failover
mechanism is available. This makes it difficult to manage and
diagnose if there is a problem. This draft analyzes the
applicability of some of the possible solutions.
</t>
</abstract>
</front>
<middle>
<section anchor="Problem" title="Introduction">
<t>
In <xref target="RFC6333">DS-Lite</xref>, the IPv4-in-IPv6
DS-Lite tunnel is stateless, no status information about the
tunnel is available, and no keep-alive mechanism is
available. It is difficult to know whether the tunnel is up or
down; and if there is a link problem, the Basic Bridging
BroadBand (B4) element can not automatically switch to another
Address Family Transition Router (AFTR) so as to continue the
network service automatically, without the involvement of
operators. This lack of failure detection and failover creates
problems for network operation and maintenance.
</t>
<t>
Possible solutions for failure detection include the usage of
Bidirectional Forwarding Detection (BFD), the Port Control
Protocol (PCP), and the Internet Control Message Protocol
(ICMP). The properties of these solutions are discussed in
this document and guidelines are provided how to implement
failure detection and automatic failover.
</t>
<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">RFC 2119</xref>.
</t>
</section>
<section title="Terminology">
<t>
<list hangIndent="10" style="hanging">
<t hangText="AFTR:">Address Family Transition Router.</t>
<t hangText="B4:">Basic Bridging BroadBand.</t>
<t hangText="BBF:">BroadBand Forum.</t>
<t hangText="BFD:">Bidirectional Forwarding Detection.</t>
<t hangText="CPE:">Customer Premise Equipment (i.e., the DS-Lite B4).</t>
<t hangText="FQDN:">Fully Qualified Domain Name.</t>
<t hangText="PCP:">Port Control Protocol.</t>
<t hangText="ICMP:">Internet Control Message Protocol.</t>
</list>
</t>
</section>
<section title="Solutions">
<section title="Bidirectional Forwarding Detection (BFD)">
<t>
<xref target="RFC5880">Bidirectional Forwarding
Detection</xref> (BFD) is a mechanism intended to detect
faults in a bidirectional path. It is usually used in
conjunction with applications like OSPF, IS-IS, for fast
fault recovery and fast
re-route <xref target="RFC5882"></xref>. BFD is being made
mandatory for keep-alive for subscriber sessions, including
DS-Lite, by the BroadBand Forum
(BBF) <xref target="WT-146"></xref>.
</t>
<t>
BFD can be used in DS-Lite, by creating a BFD session
between the B4 element and the AFTR to provide tunnel status
information. If a fault is detected, the B4 element can try
to create a DS-Lite tunnel with another AFTR and terminate
the existing one, so as to continue network service.
</t>
<t>
<xref target="I-D.vinokour-bfd-dhcp"></xref> proposes using
a DHCP option to distribute BFD parameters to B4
elements. But in case of DS-Lite, some of the key BFD
parameters are already available (e.g., peer IP address),
and other parameters can be negotiated by BFD signaling or
statically configured, so that no extra DHCP option(s) need
to be defined.
</t>
<section title="DS-Lite Scenario">
<t>
In <xref target="RFC6333">DS-Lite</xref>, the BFD packet
SHOULD be sent through an IPv4-in-IPv6 tunnel, as shown in
<xref target="DS-Lite-Scenario"></xref>. The IPv4
addresses of the B4 element and the AFTR SHOULD be the
endpoints of a BFD session.
</t>
<figure title="DS-Lite Scenario"
anchor="DS-Lite-Scenario"
align="center">
<artwork>
+--------------+ +--------------+
+------+ | | +------+ | |
| |-----+--------------+-----| | | |
| CPE | IPv6 Tunnel | AFTR |-----| IPv4 Network |
| (B4) |-----+--------------+-----| | | |
+------+ | IPv6 Network | +------+ | |
192.0.2.2 +--------------+ 192.0.2.1 +--------------+
</artwork>
</figure>
</section>
<section title="Parameters for BFD">
<t>
In order to set up a BFD session, the following parameters
are needed, as shown in Section 4.1
of <xref target="RFC5880"></xref>:
</t>
<t><list style="symbols">
<t>Peer IP address</t>
<t>My Discriminator</t>
<t>Your Discriminator</t>
<t>Desired Min TX Interval</t>
<t>Required Min RX Interval</t>
<t>Required Min Echo RX Interval</t>
</list></t>
<t>
In <xref target="RFC6334">DS-Lite</xref>, the B4's
WAN-side IPv4 address is the well-known address 192.0.2.2,
and the AFTR's well-known IPv4 address is 192.0.2.1, as
defined in section 5.7 of <xref target="RFC6333"></xref>.
The B4 element needs to create an IPv6 tunnel to an AFTR
so as to get network connectivity to the AFTR, and send
IPv4 BFD packets through the tunnel to manage it.
</t>
<t>
The other parameters listed above can be negotiated by BFD
signaling, and initial values can be configured on B4
elements and AFTRs.
</t>
</section>
<section title="Elements of Procedure">
<t>
When a B4 element gets online, it will be assigned an IPv6
prefix or address, and also the FQDN of the AFTR, as
defined in <xref target="RFC6334"></xref>. The B4 element
will create an IPv6 tunnel to the AFTR with which the B4
element can initiate a BFD session to the AFTR. BFD
packets will be sent through the DS-Lite tunnel. As
defined in section 4 of <xref target="RFC5881"></xref>,
BFD control packets MUST be sent in UDP packets with
destination port 3784, and BFD echo packets MUST be sent
in UDP packets with destination port 3785.
</t>
<t>
When sending out the first BFD packet, the B4 element can
generate a unique local discriminator, and set the remote
discriminator to zero. When the AFTR receives the first
BFD packet from a B4 element, the AFTR will also generate
a corresponding local discriminator, and put it in the
response packet to the B4 element. This will finish the
discriminator negotiation in the B4 to AFTR direction,
without any manual configuration.
</t>
<t>
When an AFTR receives the first packet from a B4 element,
the AFTR will get the IPv6 address and discriminator of
the B4 element, so that the AFTR can initiate the BFD
session in the other direction and a similar discriminator
negotiation can be carried out.
</t>
</section>
<section title="Implementation Considerations">
<t>
BFD is usually used for quick fault detection, at a very
small time scale, e.g. milliseconds. But in DS-Lite, it
may not be necessary to detect faults in such a short
time. On the other hand, an AFTR may need to support tens
of thousands of B4 elements, which means an AFTR will need
to support the same number of BFD sessions. In order to
meet performance requirements on an AFTR, it may be
necessary to configure the time period between BFD packet
transmissions to a longer time, e.g., 10s or 30s.
</t>
</section>
</section>
<section title="Port Control Protocol (PCP)">
<t>
<xref target="I-D.ietf-pcp-base-29">PCP</xref> is a NAT
traversal tool. It can also be used for network connectivity
test if PCP is supported in the network. A common use case
of PCP is to create a pinhole so that external users can
visit the servers located behind a NAT. The lifetime of the
pinhole mapping is usually long, e.g., hours, and the
lifetime will be refreshed periodically by the client before
it is expired. For the purpose of network connectivity
tests, a B4 element can create a mapping in the CGN via PCP,
with a short life time, e.g., 10s of seconds, and keep on
refreshing the mapping before it expires. If any refresh
requests fail, the B4 element knows that something is wrong
with the link or the PCP server or the CGN.
</t>
<t>
In order to detect the network connectivity of the DS-Lite
tunnel, the encapsulation mode MUST be used for PCP: PCP
packets are sent through the DS-Lite tunnel.
</t>
</section>
<section title="Internet Control Message Protocol (ICMP)">
<t>
The Echo (Request) and Echo Response messages of the
Internet Control Message Protocol (ICMP) <xref
target="RFC0792"/> <xref target="RFC4443"/> can be used to
determine whether remote nodes are reachable. In case of
DS-Lite, a B4 element can send Echo (Request) packets to the
AFTR periodically. If the B4 element does not receive a
certain number (e.g., 3) of Echo Response packets in a
certain timeout period, then the B4 element decides that a
fault has been detected.
</t>
<t>
In order to test the connectivity of DS-Lite tunnel, Echo
(Request) packets MUST be sent using ICMPv4, rather than
ICMPv6.
</t>
</section>
</section>
<section title="Discussion">
<t>
The solutions can be compared based on the failure detection
time, the overhead on the wire, and the scalability on the
AFTR. Lets consider an AFTR that needs to support 10000-30000
subscribers. If every subscriber sends a probe packet every 30
seconds, this creates a load of 1-3 probe packets per
millisecond and a failure detection delay in minutes (since
multiple probe packets may need to fail in order to detect a
failure). Shorter detection times significantly increase the
load on AFTRs.
</t>
<t>
BFD has a simple and fixed packet format, which is easy to
implement by logic devices (e.g., ASIC, FPGA). This allows
line cards to process BFD packets very efficiently in
hardware.
</t>
<t>
PCP is a control protocol typically implemented in
software. As such, processing a large number of PCP requests
in order to detect failures is relatively expensive. On the
other hand, PCP can detect the failure of more components of
the DS-Lite system. Besides failures of the link and the
routing, it also covers certain NAT functions.
</t>
<t>
Since ICMP is an integral part of any IP implementation, the
usage of ICMP messages to detect tunnel failures does not
require any special implementation efforts on the B4 elements.
However, on AFTRs that process ICMP messages in software (slow
path) rather than in hardware, the usage of ICMP messages
might lead to scalability issues.
</t>
</section>
<section title="Failover">
<t>
The FQDN of the AFTR is sent to the B4 element via a DHCP
option, as defined in <xref target="RFC6334"></xref>.
Multiple IP addresses can be configured for the FQDN of an
AFTR on the DNS server. If a B4 element detects a failure on
the link to the AFTR, the B4 element MUST terminate the
current DS-Lite tunnel, choose another AFTR address in the
list, and create a tunnel to the new AFTR. If necessary, the
B4 element SHOULD re-configure the connectivity test tool
accordingly and restart the test procedures.
</t>
<t>
Anycasts may also be used for failover. But there is an
ICMP-error-message problem with anycast, that is, when a
packet is sent from the AFTR to a B4 element, if one of the
routers along the path generates an ICMP error message, e.g.,
Packet Too Big (PTB), then the error message may not be sent
back to the source AFTR but to another AFTR.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
This memo includes no request to IANA.
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
In the <xref target="RFC6333">DS-Lite</xref> application, the
B4 element may not be directly connected to the AFTR; there
may be other routers between them. In such a deployment, there
are potential spoofing problems, as described in
<xref target="RFC5883"/>. Hence cryptographic authentication
SHOULD be used with BFD as described in
<xref target="RFC5880"/> if security is concerned.
</t>
</section>
<!--
<section title="Acknowledgements">
<t>
The authors would like to thank Mohamed Boucadair for his
useful comments.
</t>
</section>
-->
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
&RFC0792;
&RFC2119;
&RFC4443;
&RFC5880;
&RFC5881;
&RFC5882;
&RFC5883;
&RFC6333;
&RFC6334;
<reference anchor="I-D.ietf-pcp-base-29">
<front>
<title>Port Control Protocol (PCP) (work in progress)</title>
<author initials="D." surname="Wing" fullname="Dan Wing">
<organization>Cisco Systems, Inc.</organization>
</author>
<author initials="S." surname="Cheshire" fullname="Stuart Cheshire">
<organization>Apple Inc.</organization>
</author>
<author initials="M." surname="Boucadair" fullname="Mohamed Boucadair">
<organization>France Telecom</organization>
</author>
<author initials="R." surname="Penno" fullname="Reinaldo Penno">
<organization>Juniper Networks</organization>
</author>
<author initials="P." surname="Selkirk" fullname="Paul Selkirk">
<organization>Internet Systems Consortium</organization>
</author>
<date month="Nov." year="2012" />
</front>
</reference>
<reference anchor="WT-146">
<front>
<title>WT-146 Subscriber Sessions (work in progress)</title>
<author initials="A." surname="Kavanagh" fullname="Alan Kavanagh">
<organization>Ericsson</organization>
</author>
<author initials="F." surname="Klamm" fullname="Frederic Klamm">
<organization>Apple Inc.</organization>
</author>
<author initials="W." surname="Boucadair" fullname="Wojciech Dec">
<organization>France Telecom</organization>
</author>
<author initials="R." surname="Dec" fullname="Reinaldo Penno">
<organization>Cisco Systems</organization>
</author>
<date month="Apr" year="2012" />
</front>
</reference>
</references>
<references title="Informative References">
<reference anchor="I-D.vinokour-bfd-dhcp">
<front>
<title>Configuring BFD with DHCP and Other Musings</title>
<author initials="V." surname="Vinokour" fullname="Vitali Vinokour">
<organization>Cisco Systems</organization>
</author>
<date month="May" year="2008" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:08:29 |