Internet DRAFT - draft-xu-ospf-multi-homing-ipv6

draft-xu-ospf-multi-homing-ipv6







Network Working Group                                              M. Xu
Internet-Draft                                                   S. Yang
Expires: April 13, 2016                                            J. Wu
                                                     Tsinghua University
                                                                F. Baker
                                                           Cisco Systems
                                                        October 11, 2015


                Extending OSPFv3 to Support Multi-homing
                   draft-xu-ospf-multi-homing-ipv6-00

Abstract

   Traditionally, routing protocols make routing decisions solely based
   on destination IP addresses, packets towards the same destination
   will be delivered to the same next hop no matter where they come
   from.  These protocols work well with simple networks that have only
   one egress router.  However, in the multi-homing scenario, packets
   may be dropped if forwarded only based on destination addresses.

   This document defines enhancements to the OSPFv3 protocol that allow
   simple and flexible operations, with which packets will be routed
   towards the corresponding upstream ISPs based on both destination and
   source addresses.

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 April 13, 2016.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Xu, et al.               Expires April 13, 2016                 [Page 1]

Internet-Draft  Extending OSPFv3 to Support Multi-homing    October 2015


   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.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Router Behavior . . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Egress Router Behavior  . . . . . . . . . . . . . . . . .   5
     4.2.  Interior Router Behavior  . . . . . . . . . . . . . . . .   5
   5.  TC-LSA Format . . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Routing Table Structure . . . . . . . . . . . . . . . . . . .   8
   7.  Calculation of the Routing Table  . . . . . . . . . . . . . .   9
   8.  Matching Rule . . . . . . . . . . . . . . . . . . . . . . . .   9
   9.  Compatibility . . . . . . . . . . . . . . . . . . . . . . . .   9
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  10
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     12.2.  Informative References . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   Networks are growing both in device count and in complexity.  Today
   they are generally connected with multiple upstream providers, and
   may require routing to place audio/visual entertainment traffic one
   one path, office services on another.  Traditionally, we have



Xu, et al.               Expires April 13, 2016                 [Page 2]

Internet-Draft  Extending OSPFv3 to Support Multi-homing    October 2015


   simplified networks using a single exit router.  Increasingly, such
   networks are multi-homed.

   Traditionally, routing protocols make routing decisions solely based
   on destination IP addresses, packets towards the same destination
   will be delivered to the same next hop no matter where they come
   from.  These protocols work well with simple networks that have only
   one egress router.  However, in the multi-homing scenario, packets
   may be dropped if forwarded only based on destination addresses
   [RFC3704].

   Although many patch-like solutions, like static routing, policy-based
   routing (PBR), multi-topology routing (MTR) and layer-3 VPN can solve
   the problem, they complex the configurations in networks, and are not
   suitable for ISP administrators.  We need a simple solution to help
   administrators manage their networks in the multi-homing scenario.

   In this document, we define enhancements to OSPFv3 that allow
   networks route packets towards the corresponding upstream ISPs,
   according to both destination and source addresses.  The enhancements
   defined in this memo are backward-compatible with the OSPFv3
   specification defined in [RFC5340], and with the OSPF extensions
   defined in [I-D.ietf-ospf-ospfv3-lsa-extend]

2.  Terminology

   Terminology used in this document:

   o  Traffic Class (TC): Identified by (destination prefix, source
      prefix), all packets falling in the domain belong to the traffic
      class.

   o  TC-Route: Identified by (destination prefix, source prefix,
      value), where value is the administrative value applied to the
      traffic class (destination prefix, source prefix).

   o  TC-LSA: Link state advertisement that communicates the
      reachability for a traffic classes.

3.  Overview

   Traditionally, egress routers obtain delegated prefixes from upstream
   ISPs using DHCPv6 with prefix options [RFC3633].  The egress routers
   will then assign longer sub-prefixes to the other links in the
   network.  Each router inside the network will act as standard OSPFv3
   router, and forward packets based on their destination addresses.





Xu, et al.               Expires April 13, 2016                 [Page 3]

Internet-Draft  Extending OSPFv3 to Support Multi-homing    October 2015


   With traffic class routing, after obtaining delegated prefixes and
   assigning sub-prefixes, egress routers will populate traffic classes
   (with extended LSAs), rather than destination address only, into the
   network.  Each internal router will flood these traffic classes
   information.  When calculating the path towards a destination
   address, routers will take the traffic classes into considerations.
   Intrinsically, in traditional routing model, the object being routed
   to is a destination prefix; in the new routing model, the object
   being routed might be a destination prefix given that the packet
   sports a certain source prefix.

   Each traffic class is associated with a cost, which is a single
   dimensionless metric.

   For example, as shown in Figure 1, a site is connected to the
   Internet through two ISPs, ISP1 and ISP2.  ISP1 delegates prefix P1
   to the site, and ISP2 delegates prefix P2 to the site.  After being
   delegated with P1, the egress router E1 of the site will advertise a
   traffic class - {::/0, P1}, into the site.  After being delegated
   with P2, the egress router E2 of the site will advertise a traffic
   class - {::/0, P2}, into the site.  Receiving these advertisements,
   interior router I1 will compute two paths towards ::/0, one through
   router E1 for traffic from P1, the other through E2 for traffic from
   P2.



























Xu, et al.               Expires April 13, 2016                 [Page 4]

Internet-Draft  Extending OSPFv3 to Support Multi-homing    October 2015


               +---------------+                  +-----------------+
               |               |                  |                 |
               |   ISP1: P1    |                  |    ISP2: P2     |
               |               |                  |                 |
               +--------+------+                  +-----+-----------+
                        |                               |
                     +--+---+                        +--+---+
                     |Router|                        |Router|
                     | BR1  |                        | BR2  |
                     +---+--+                        +---+--+
                   ------+----------          -----------+-----
                         |                               |
                     +---+--+                        +---+--+
                     |Router|                        |Router|
                     |  E1  |                        |  E2  |
                     +------+       +------+         +------+
                           -+-------+Router+---------+-
                                    |  I1  |
                                    +--+---+
                                    +--+---+  Address A in P1
                                    | Host |
                                    +------+  Address B in P2


                      Figure 1: Multi-homing Scenario

4.  Router Behavior

   All routers behave like traditional OSPFv3 routers, however, the
   following behaviors are different with traditional OSPFv3 routers.

4.1.  Egress Router Behavior

   After obtaining delegated prefixes using DHCPv6 with prefix options,
   an egress router should originate TC-LSAs, i.e., extended LSAs with
   source prefixes appended.  Egress routers then will advertise these
   TC-LSAs into the network.

   Note that an egress router behaves like an interior router if it
   receives a TC-LSA from other egress routers.

4.2.  Interior Router Behavior

   Receiving TC-LSAs from egress routers, an interior router should
   store the TC-LSAs into its LSDB, and flood it to other routers.
   After calculating a path to an egress router advertising
   reachability, i.e., a destination prefix, the interior router should
   decide which traffic class can follow this path towards the egress



Xu, et al.               Expires April 13, 2016                 [Page 5]

Internet-Draft  Extending OSPFv3 to Support Multi-homing    October 2015


   router.  If a traffic class can travel through two different paths,
   then interior router should compare their costs, and select the path
   with the lowest cost.

   Interior routers contains a routing table that contains all necessary
   information to forward an IP packet following the path of a traffic
   class.  After computing the path towards a traffic class, interior
   routers should update the entry in the routing table if necessary,
   e.g., change the next hop towards the traffic class.  The routing
   table structure will be described in Section 6.  Calculation of
   routing table will be illustrated in Section 7.

   At last, interior routers should update the Forwarding Information
   Base (FIB), which will be discussed in the next version of this
   document.

5.  TC-LSA Format

   TC-LSA adds TLV extensions, which contains source prefix information,
   based on original OSPFv3 LSA.  We follow the TLV format in
   [I-D.baker-ipv6-ospf-dst-src-routing] and extended LSA format in
   [I-D.ietf-ospf-ospfv3-lsa-extend].

   Each extended LSA includes the traditional LSA part in [RFC5340], and
   one or more TLVs defined in [I-D.baker-ipv6-ospf-dst-src-routing].
   But we do not need all LSAs to be extended, the LSAs need to be
   extended are as follows:

   o  Intra-Area-Prefix-LSA: The extended LSA has type 0x2029.

   The extended LSA format for Intra-Area-Prefix-LSA in multi-homing is
   shown in Figure 2.



















Xu, et al.               Expires April 13, 2016                 [Page 6]

Internet-Draft  Extending OSPFv3 to Support Multi-homing    October 2015


        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           LS Age              |0|0|1|       LSA Type          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Link State ID                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Advertising Router                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   LS Sequence Number                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        LS Checksum            |          LSA Length           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       # Prefixes              |     Referenced LS Type        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Referenced Link State ID                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |               Referenced Advertising Router                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  PrefixLength | PrefixOptions |          Metric               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Address Prefix                         |
       |                             ...                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                             ...                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  PrefixLength | PrefixOptions |          Metric               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Address Prefix                         |
       |                             ...                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           TLV Type            |        TLV Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | SPrefixLength | SPrefixOptions|               0               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Source Address Prefix                        |
       |                             ...                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


              Figure 2: Extended Intra-Area-Prefix-LSA format

   All LSA header fields are the same as defined in [RFC5340], except
   the following:

   o  LSA type: The LSA type value is 0x2029, according to
      [I-D.ietf-ospf-ospfv3-lsa-extend];




Xu, et al.               Expires April 13, 2016                 [Page 7]

Internet-Draft  Extending OSPFv3 to Support Multi-homing    October 2015


   o  LSA length: The length of the whole LSA header, including the
      TLVs;

   o  TLV type: The type of IPv6 source prefix TLV, assigned by IANA;

   o  TLV length: The value is 20 as defined in
      [I-D.baker-ipv6-ospf-dst-src-routing];

   o  SPrefixLength, SPrefixOptions, Source Address Prefix:
      Representation of the IPv6 address prefix, which is delegated from
      the upstream ISP providers;

   In the extended LSA, suppose there are n destination prefix d1, d2,
   ..., dn, and 1 source prefix s, then the LSA carries n TC-route
   announcement, (d1, s, v1), (d2, s, v2), ..., (dn, s, vn), where vi is
   the metric associated with destination prefix di.

6.  Routing Table Structure

   For traditional routing, the routing table structure contains all
   needed information to forward IP packets to the right destination.
   For example, destination prefixes are commonly structured into a
   prefix trie, where each trie nodes contain the necessary information.
   Routers can lookup and update the prefix trie.

   With traffic classes, the routing table structure must contain all
   needed information to forward IP packets following the right traffic
   class, i.e., towards the related destination and from the related
   source.  For each routing table entry, there are two additional
   fields other than the fields mentioned in [RFC5340]:

   o  Source IP Address: The IP address of the source in traffic class.

   o  Source Address Mask: If the source is a subnet, then it is
      referred to as the subnet mask.

   The routing table must provide interface for update and lookup in it.
   For example, traffic classes can be structured into a two dimensional
   (or two level) trie, where each trie node in the first dimension
   points to a sub-trie in the second dimension.  The trie nodes in the
   second dimension contain the necessary information to forward IP
   packets following the right traffic class.

   There exist multiple implementation in real routers.  For example, 1)
   we can add an additional routing table besides the destination-based
   routing table; 2) the destination-based routing table can be extended
   to support the new structure, in which case all destination-based
   rule can be appended with a wildcard IPv6 address prefix as the



Xu, et al.               Expires April 13, 2016                 [Page 8]

Internet-Draft  Extending OSPFv3 to Support Multi-homing    October 2015


   source prefix.  The specific implementation for routing table is out
   of scope of this document.

7.  Calculation of the Routing Table

   The fundamental algorithm in OSPFv3 doesn't change.  The algorithm
   uses the SPF approach to calculate a path to the router advertising
   reachability, and then uses the reachability advertisement to decide
   what traffic should follow that route.  What we are changing is the
   reachability advertisement, in traiditional OSPFv3, the
   advertisements, which is one or several kinds of LSAs, represent
   destination prefixes; in this document, the advertisements, which is
   one or several kinds of TC-LSAs, represent traffic classes.

   Note that we do not have to change router-LSA and network-LSA in
   [RFC5340].  Thus, the first stage of Section 4.8.1 in [RFC5340]
   remains the same in this document.  However, the second stage of
   Section 4.8.1 in [RFC5340] should change by a little bit.  Instead of
   examining the list of the intra-area-prefix-LSAs, the list of
   extended intra-area-prefix-LSAs is examined.  The cost of any
   advertised traffic class is the sum of the class' advertised metric
   plus the cost of the transit vertex (either router or transit
   network) indentified by extended intra-area-prefix-LSAs' referenced
   LS type, referenced link state ID, and referenced advertising router
   field.

8.  Matching Rule

   We also adopt the LMF (longest match first) rule when a packet
   matches multiple routing entries.  However, traffic class has two
   dimensions, there might exist ambiguity.  For example, if there
   exists two routing entries, (d1, s1, nexthop1), (d2, s2, nexthop2),
   where d1 is longer than d2 and s2 is longer than s1, then none entry
   is longer than the other in both dimensions.  In this situation, we
   must insert an additional entry into the routing table, e.g., (d1,
   s2, nexthop1) in the above example.  The entry directs to nexthop1
   rather than nexthop2, because we must guarantee consistency among
   routers.

9.  Compatibility

   With the enhancements, incremental deployment is possible.  The un-
   deployed routers act according to [RFC5340], and will drop the
   extended LSA packets when receiving them.







Xu, et al.               Expires April 13, 2016                 [Page 9]

Internet-Draft  Extending OSPFv3 to Support Multi-homing    October 2015


10.  IANA Considerations

   The newly LSA types and TLVs should be assigned by IANA, please refer
   to [I-D.baker-ipv6-ospf-dst-src-routing] and
   [I-D.ietf-ospf-ospfv3-lsa-extend].

11.  Acknowledgments

   Zheng Liu and Gautier Bayzelon provided useful input into this
   document.

12.  References

12.1.  Normative References

   [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
              Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
              2004, <http://www.rfc-editor.org/info/rfc3704>.

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              DOI 10.17487/RFC3633, December 2003,
              <http://www.rfc-editor.org/info/rfc3633>.

   [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
              for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
              <http://www.rfc-editor.org/info/rfc5340>.

12.2.  Informative References

   [I-D.baker-ipv6-ospf-dst-src-routing]
              Baker, F., "IPv6 Source/Destination Routing using OSPFv3",
              draft-baker-ipv6-ospf-dst-src-routing-03 (work in
              progress), August 2013.

   [I-D.ietf-ospf-ospfv3-lsa-extend]
              Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3
              LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-07
              (work in progress), August 2015.

Authors' Addresses










Xu, et al.               Expires April 13, 2016                [Page 10]

Internet-Draft  Extending OSPFv3 to Support Multi-homing    October 2015


   Mingwei Xu
   Tsinghua University
   Department of Computer Science, Tsinghua University
   Beijing  100084
   P.R. China

   Phone: +86-10-6278-1572
   Email: xumw@tsinghua.edu.cn


   Shu Yang
   Graduate School at Shenzhen, Tsinghua University
   Division of Information Science and Technology
   Shenzhen  518055
   P.R. China

   Phone: +86-755-2603-6059
   Email: yang.shu@sz.tsinghua.edu.cn


   Jianping Wu
   Tsinghua University
   Department of Computer Science, Tsinghua University
   Beijing  100084
   P.R. China

   Phone: +86-10-6278-5983
   Email: jianping@cernet.edu.cn


   Fred Baker
   Cisco Systems
   Santa Barbara, California  93117
   USA

   Email: fred@cisco.com















Xu, et al.               Expires April 13, 2016                [Page 11]