[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06                                          
Internet Engineering Task Force                             T. Tsou, Ed.
Internet-Draft                                 Huawei Technologies (USA)
Intended status: Informational                            March 12, 2012
Expires: September 13, 2012


                          BFD Support DS-Lite
                   draft-tsou-softwire-bfd-ds-lite-01

Abstract

   In DS-Lite, the tunnel is not associated with any state information,
   which makes it difficult to manage and diagnose.  Some tools may be
   used to resolve this problem.

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 September 13, 2012.

Copyright Notice

   Copyright (c) 2012 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
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.





Tsou                   Expires September 13, 2012               [Page 1]


Internet-Draft                 BFD DS-Lite                    March 2012


Table of Contents

   1.  Problem statement . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
     3.1.  BFD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
       3.1.1.  DS-Lite Scenario  . . . . . . . . . . . . . . . . . . . 4
       3.1.2.  Parameters for BFD  . . . . . . . . . . . . . . . . . . 4
       3.1.3.  Procedures  . . . . . . . . . . . . . . . . . . . . . . 5
       3.1.4.  Implementation Considerations . . . . . . . . . . . . . 6
     3.2.  PCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     3.3.  PING  . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
   4.  Failover  . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 8






























Tsou                   Expires September 13, 2012               [Page 2]


Internet-Draft                 BFD DS-Lite                    March 2012


1.  Problem statement

   In DS-Lite [RFC6333], the IPv4-in-IPv6 tunnel is stateless, no status
   information about tunnel is available, and no keep-alive mechanism is
   available.  It is difficult to know whether the tunnle is up or down,
   which creates a problem for operation and maintenance.

   If a B4 can detect a failure in the link to AFTR, it can switch to
   another AFTR, setup new tunnel to that AFTR, so as to continue the
   network service.  Anycast could be used for the same purpose --
   failover, but there is an ICMP error message problem, that is, when a
   packet is sent from AFTR to B4, one of the routers along the path may
   generate an error ICMP message, e.g., packet too big, and the error
   message is not sent back to the source AFTR, but sent to another
   AFTR.

   In some cases, the operators may want to have some more diagnostic
   functions besides connectivity test, e.g. delay and throughput test,
   this may be useful if the operator is providing services like IPTV
   and video conference.  ETHOAM and BFD can provide these
   functionalities.  But ETHOAM[802.1ag - 2007]is for ethernet layer2;
   and BFD OAM functions now is only available for MPLS-TP[RFC6374].
   This is currently out of the scope of this spec.

1.1.  Requirements Language

   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 RFC 2119 [RFC2119].


2.  Terminology

   AFTR:     Address Family Transition Router.

   B4:       Basic Bridging BroadBand.

   BFD:      Bidirectional Forwarding Detection.

   CPE:      Customer Premise Equipment (i.e., the DS-Lite B4).

   FQDN      Fully Qualified Domain Name.

   PCP       Port Control Protocol.







Tsou                   Expires September 13, 2012               [Page 3]


Internet-Draft                 BFD DS-Lite                    March 2012


3.  Solutions

3.1.  BFD

   BFD is a mechanism intended to detect faults in the bidirectional
   path.  It is usually used in conjunction with applications like OSPF,
   IS-IS, etc, for fast fault recovery/fast re-route.  [RFC5882]

   BFD [RFC5880]can be used in DS-Lite, by creating a BFD session
   between the B4 and the AFTR to provide tunnel status information.  If
   a fault is detected the B4 can try to create a DS-Lite tunnel with
   another AFTR and terminate the existing one, so as to continue
   network service.

   [I-D.vinokour-bfd-dhcp]proposes using a DHCP option to distribute BFD
   parameters to the B4.  But in case of DS-Lite, some of the key BFD
   parameters are already available (e.g., peer IP address is already
   available), and other parameters can be negotiated by BFD signaling
   or statically configured, so that no extra DHCP option(s) need to be
   defined.

3.1.1.  DS-Lite Scenario

   In DS-Lite [RFC6333], the BFD packet SHOULD be sent through an IPv4-
   in-IPv6 tunnel, as shown in Figure 1.  The IPv4 addresses of the B4
   and AFTR SHOULD be the endpoints of a BFD session.

                    +--------------+                  +--------------+
       +------+     |              |     +------+     |              |
       |      |-----+--------------+-----|      |     |              |
       | CPE  |       IPv6 Tunnel        | AFTR |-----| IPv4 Network |
       | (B4) |-----+--------------+-----|      |     |              |
       +------+     | IPv6 Network |     +------+     |              |
      192.0.0.2     +--------------+    192.0.0.1     +--------------+

                        Figure 1: DS-Lite Scenario

3.1.2.  Parameters for BFD

   In order to set up a BFD session, the following parameters are
   needed, as shown in Section 4.1 of[RFC5880]:

   o  Peer IP address

   o  My Discriminator

   o  Your Discriminator




Tsou                   Expires September 13, 2012               [Page 4]


Internet-Draft                 BFD DS-Lite                    March 2012


   o  Desired Min TX Interval

   o  Required Min RX Interval

   o  Required Min Echo RX Interval

   In DS-Lite [RFC6334], the B4 WAN-side IPv4 address is a well-known
   address 192.0.0.2, and the AFTR's IPv4 address is 192.0.0.1, as
   defined in section 5.7 of[RFC6333].  Because all the B4s and AFTRs
   use the same well-known IP addresses, IPv4 addresses are not
   sufficient for setting up a BFD session.  From the B4's point of
   view, the B4 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.  In Section 6 of [RFC5881], "and that
   subsequent BFD packets MUST be demultiplexed solely by the Your
   Discriminator field (as is always the case).", the AFTR need to bind
   each Your Discriminator with a B4's IPv6 address so as to distinguish
   a B4.

   The other parameters listed above can be negotiated by BFD signaling,
   and initial values can be configured on the B4 and AFTR.

3.1.3.  Procedures

   In DS-Lite [RFC6333], when a B4 gets online, it will be assigned an
   IPv6 prefix/address, and also the FQDN of the AFTR, as defined in
   [RFC6334].  The B4 will create an IPv6 tunnel to the AFTR with which,
   along with the well known B4 IPv4 address 192.0.0.2 and AFTR IPv4
   address 192.0.0.1, the B4 can initiate a BFD session to the AFTR.
   BFD packets will be sent through DS-Lite tunnel.  As defined in
   section 4 of [RFC5881], BFD control packet MUST be sent in UDP packet
   with destination port 3784, and BFD echo packet MUST be sent in UDP
   packet with destination port 3785.

   When sending out the first BFD packet, the B4 can generate a unique
   local discriminator, and set the remote discriminator to zero.  When
   the AFTR receive the first BFD packet from a B4, the AFTR will also
   generate a corresponding local discriminator, and put it in the
   response packet to the B4.  This will finish the discriminator
   negotiation in the B4 to AFTR direction, without any manual
   configuration.

   When the AFTR receives the first packet from a B4, AFTR will get the
   IPv6 address and discriminator of the B4, so that the AFTR can
   initiate the BFD session in the other direction and a similar
   discriminator negotiation can be carried out.





Tsou                   Expires September 13, 2012               [Page 5]


Internet-Draft                 BFD DS-Lite                    March 2012


3.1.4.  Implementation Considerations

   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 B4s, which means the AFTR will
   need to support the same number of BFD sessions.  In order to meet
   performance requirements on the AFTR, it may be necessary to extend
   the time period between BFD packet transmissions to a longer time,
   e.g., 10s or 30s.

3.2.  PCP

   PCP [I-D.ietf-pcp-base-23] is a NAT traversal tool, and 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 pinhole so that
   external users can visit the serviers located behind a NAT, and 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 test, B4 can create
   a mapping in the CGN via PCP, with short life time, e.g. 10s of
   seconds, and keep on refreshing the mapping before it is expired.  If
   any refresh request fail, B4 knows that something is wrong with the
   link or the PCP server or CGN.

   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 DS-Lite tunnel.  Encapsulation mode and plain mode are two
   alternatives for PCP, there is no concensus yet which one should be
   prefered in the PCP spec.

3.3.  PING

   PING is a common tool used for network node reachability tes, most of
   the network nodes provide this tool.  In case of DS-Lite, B4 can send
   PING packets to AFTR periodically.  If B4 does not receive response
   packets for a certain number of PING request packet, e.g. 3, then B4
   decides that a fault is detected.

   In order to test the connectivity of DS-Lite tunnel, PING packets
   MUST be sent using ICMPv4, rather than ICMPv6.


4.  Failover

   The FQDN of the AFTR is sent to B4 via a DHCP option, as defined in
   [RFC6334].  Multiple IP addresses can be configured for an FQDN on
   the DNS server.  If B4 detect a failure on the link to AFTR, B4 MUST



Tsou                   Expires September 13, 2012               [Page 6]


Internet-Draft                 BFD DS-Lite                    March 2012


   terminate the current DS-Lite tunnel, choose another AFTR address in
   the list, and create a tunnel to the new AFTR.  B4 SHOULD also re-
   configure the connectivity test tool accordingly if necessary, and
   restart the test procedures.


5.  IANA Considerations

   This memo includes no request to IANA.


6.  Security Considerations

   In DS-Lite [RFC6333], the B4 may not be directly connected to the
   AFTR; there may be other routers between them.  Then there are
   potential spoofing problems, as described in [RFC5883].  Hence
   cryptographic authentication SHOULD be used as described in [RFC5880]
   if security is concerned.


7.  Acknowledgements

   The author would like to thank Mohamed Boucadair for his useful
   comments, more solutions are included in this memo.


8.  References

8.1.  Normative References

   [I-D.ietf-pcp-base-23]
              Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
              Selkirk, "Port Control Protocol (PCP)(work in progress)",
              Feb 2012.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD)", RFC 5880, June 2010.

   [RFC5881]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
              June 2010.

   [RFC5882]  Katz, D. and D. Ward, "Generic Application of
              Bidirectional Forwarding Detection (BFD)", RFC 5882,
              June 2010.



Tsou                   Expires September 13, 2012               [Page 7]


Internet-Draft                 BFD DS-Lite                    March 2012


   [RFC5883]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD) for Multihop Paths", RFC 5883, June 2010.

   [RFC6333]  Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
              Stack Lite Broadband Deployments Following IPv4
              Exhaustion", RFC 6333, August 2011.

   [RFC6334]  Hankins, D. and T. Mrugalski, "Dynamic Host Configuration
              Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite",
              RFC 6334, August 2011.

   [RFC6374]  Frost, D. and S. Bryant, "Packet Loss and Delay
              Measurement for MPLS Networks", RFC 6374, September 2011.

8.2.  Informative References

   [802.1ag - 2007]
              IEEE Computer Societ, "IEEE Standard for Local and
              Metropolitan Area Networks -  Virtual Bridged Local Area
              Networks Amendment 5: Connectivity Fault Management",
              2007.

   [I-D.vinokour-bfd-dhcp]
              Vinokour, V., "Configuring BFD with DHCP and Other
              Musings", May 2008.


Author's Address

   Tina Tsou (editor)
   Huawei Technologies (USA)
   2330 Central Expressway
   Santa Clara  CA  95050
   USA

   Phone: +1 408 330 4424
   Email: tina.tsou.zouting@huawei.com














Tsou                   Expires September 13, 2012               [Page 8]