[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                     George Swallow
Internet Draft                                       Cisco Systems, Inc.
Category: Standards Track
Expiration Date: January 2008
                                                            Jim Guichard
                                                     Cisco Systems, Inc.

                                                               July 2007


                Network Scaling with Aggregated IP LSPs


                draft-swallow-mpls-aggregated-fec-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


   Abstract

      This document defines a means for an Multiprotocol Label Switched
      network to summarize routes while maintaining end-to-end LSP
      connectivity thereby reducing the number of host routes that need
      to be carried within the interior gateway protocol.






Swallow & Guichard           Standards Track                    [Page 1]


Internet Draft  draft-swallow-mpls-aggregated-fec-00.txt       July 2007


Contents

 1      Introduction  ..............................................   3
 1.1    Conventions  ...............................................   3
 1.2    Terminology  ...............................................   3
 2      Overview  ..................................................   4
 2.1    Inter-area LSP Construction  ...............................   4
 2.2    Label forwarding operation  ................................   6
 3      Aggregated-prefix FEC  .....................................   7
 3.1    Aggregated-prefix FEC Element  .............................   7
 3.2    Label distribution procedures  .............................   7
 4      Algorithmically derived de-aggregation label  ..............   8
 5      Security Considerations  ...................................   8
 6      IANA Considerations  .......................................   8
 7      References  ................................................   8
 7.1    Normative References  ......................................   8
 7.2    Informative References  ....................................   9
 8      Authors' Addresses  ........................................   9
































Swallow & Guichard           Standards Track                    [Page 2]


Internet Draft  draft-swallow-mpls-aggregated-fec-00.txt       July 2007


1. Introduction

   The growth of next-generation Multiprotocol Label Switched
   (MPLS)-based services such as l2vpn, l3vpn and so on, have introduced
   an explosion in the number of edge devices that are needed to deploy
   such services. Typically these services require an end-to-end label-
   switched path LSP, from ingress Label-Switching Router (LSR) to
   egress LSR.  These LSPs are maintained between the host IP addresses
   of the LSRs. This requirement forces the operator to carry each host
   address for every edge device within their interior gateway protocol
   (IGP) which has a negative impact on the scale and convergence goals
   of their IGP.

   This document defines extensions to the Label Distribution Protocol
   (LDP) to provide a means for the end-to-end LSP path to be maintained
   between edge devices without the necessity of carry each and every
   host address within the IGP or to distribute labels throughout a
   domain for host addresses.  This is achieved by defining an
   Aggregated-prefix Forwarding Equivalence Class (FEC) and an
   algorithmically derived label per aggregated host route which stacked
   together form end-to-end LSPs.




1.1. Conventions

   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 [KEYWORDS].


1.2. Terminology

     ABR       Area border router
     FEC       Forwarding equivalence class
     IGP       Interior gateway protocol
     LDP       Label Distribution Protocol
     LIB       Label information base
     LSP       Label-switched path
     LSR       label-switching router
     NHLFE     Next-hop label forwarding entry
     PE        Provider edge [LSR]
     RIB       Routing information base
     VPN       Virtual private network






Swallow & Guichard           Standards Track                    [Page 3]


Internet Draft  draft-swallow-mpls-aggregated-fec-00.txt       July 2007


2. Overview

   The basic idea is to use prefix LSP to deliver MPLS packets from the
   ingress LSR to the ABRs serving the egress LSRs.  Nested within these
   LSPs are LSPs for each of the specific hosts covered by that prefix.
   This is accomplished by defining two new FECs, the Aggregated-prefix
   FEC and the De-aggregation FEC.

   The Aggregated-prefix FEC is exactly like the Prefix FEC as far as
   routing is concerned.  An Aggregated Prefix FEC differs in that at
   the end of the LSP, it forms the context for interpreting the next
   label which is bound to a De-aggregation FEC.  In that regard, an
   aggregated-prefix LSP never uses penultimate-hop popping.  Further,
   to ensure that an LSP exists all the way to an LSR capable of de-
   aggregating the FEC, labels bound to these FECs are always
   distributed in ordered mode.

   A De-aggregation FEC represents a specific host route.  It is exactly
   the same as a Host Address FEC except that labels bound to these FECs
   are not distributed in LDP.  Instead, the label value bound to a
   particular host is algorithmically derived from the host address and
   the aggregated prefix using a simple algorithm described in section 4
   below.

   The use of these FECs is illustrated in the example below.



2.1. Inter-area LSP Construction

   To illustrate the construction of inter-area LSPs consider the
   following simple topology with one backbone area and two stub areas.
   Using the mechanisms described within this document, we describe an
   LSP is built from ingress PE4 to egress PE1 with traffic destined to
   192.169.0.22/32 in VPN_1:
















Swallow & Guichard           Standards Track                    [Page 4]


Internet Draft  draft-swallow-mpls-aggregated-fec-00.txt       July 2007


                          Area 0
                    +----------------+
            Area 1  |                |  Area 2
         +----------+                +----------+
         |          |                |          |
         |          |                |       +-----+        VPN_1
         |          |                |       | PE1 |------192.169.0.22
         |          |                |       +-----+
         |          |                |          |  10.10.2.1
         |          |                |          |
      +-----+    +------+        +------+    +-----+
      | PE4 |    | ABR1 |        | ABR2 |    | PE2 |
      +-----+    +------+        +------+    +-----+
         |          |                |          |  10.10.2.2
         |          |                |          |
         |          |                |       +-----+
         |          |                |       | PE3 |
         |          |                |       +-----+
         |          |                |          |  10.10.2.3
         +----------+                +----------+
                    |                |
                    +----------------+

                 Figure 1: Example network

   All routers are MPLS enabled and MPLS connectivity is required
   between all PE routers to facilitate edge services.

   In the egress area (area 2), the records available are:

       RIB                  LIB
        10.10.2.1/32         Labels bound to:  10.10.2.1/32
        10.10.2.2/32                           10.10.2.2/32
        10.10.2.3/32                           10.10.2.3/32

   The area border router ABR2 advertises in the backbone area:

        - the aggregated IP prefix 10.10.2/24 (which covers all
   available
          PE routers in area 2) in the IGP

        - a label (say 51) bound to the Aggregated-prefix FEC 10.10.2/24
          in LDP to its neighbors in area 0.

   ABR2 algorithmically creates a label entry for each host route
   covered by the summary 10.10.2/24 (see section 4).  It then creates
   NHLFEs for each of these binding them to the next-hop labels it
   received for each of the specific routes.



Swallow & Guichard           Standards Track                    [Page 5]


Internet Draft  draft-swallow-mpls-aggregated-fec-00.txt       July 2007


   In the backbone (area 0), the records available are:

       RIB                  LIB
        10.10.2.1/32         Labels bound to:  10.10.2/24

   The area border router ABR1 receives the route 10.10.2/24 via the IGP
   and labels from its neighbors in area 0 bound to the Aggregated-
   prefix FEC 10.10.2/24 {22} via LDP from the next-hop router towards
   the route 10.10.2/24.  It redistributes both the route and a label
   bound to the FEC into area 1.

   The routers in area 1, including PE4, receive the route 10.10.2/24
   via the IGP and and labels from their neighbors bound to the
   Aggregated-prefix FEC 10.10.2/24 via LDP.

   In the ingress area (area 1), the records available are:

       RIB                  LIB
        10.10.2.1/32         Labels bound to:  10.10.2/24


2.2. Label forwarding operation

   Using the information presented in the previous section, the label
   forwarding from ingress PE4 to egress PE1 is as follows:

   PE4 has a VPN destination 192.169.0.22/32 reachable via remote PE1
   whose next-hop is 10.10.2.1/32 which is bound to say 47.  PE4 only
   has a summary route 10.10.2/24 covering the more specific next-hop
   10.10.2.1/32, but has label bindings for that aggregated FEC.  Using
   the same algorithm as the egress ABR2, PE4 determines that the de-
   aggregation label for PE1 is 17.  PE1 creates a VRF entry for
   192.169.0.22/32 which includes a three label stack consisting of its
   next-hop label for 10.10.2/24, say 22, stacked upon the de-
   aggregation label (17) stacked upon the VPN label (47).

   Thus to forward a packet 192.169.0.22/32 in VPN_1, PE4 pushes on a
   label stack {22, 17, 47}.  This is forwarded via normal label-
   switching to ABR2 where it arrives with the label stack {51, 17, 47}.
   ABR2 recognizes label 51 as context label and pops it.  It then looks
   up label 17 in the context associated 51.  ABR2 then pushes onto the
   label stack the LDP derived label for the local PE. Forwarding
   continues at this point as per normal RFC4364 procedures.








Swallow & Guichard           Standards Track                    [Page 6]


Internet Draft  draft-swallow-mpls-aggregated-fec-00.txt       July 2007


3. Aggregated-prefix FEC

   A FEC TLV is defined in [LDP] section 3.4.1. This TLV serves as a
   container for FEC Elements.  To enable distribution of the
   Aggregated-prefix FEC, we define a new FEC Element.



3.1. Aggregated-prefix FEC Element

      Aggregated-prefix FEC Element value encoding:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Prefix (TBD)   |     Address Family            |   PreLen    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Prefix                                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Address Family

         Two octet quantity containing a value from ADDRESS FAMILY
         NUMBERS in [RFC1700] that encodes the address family for the
         address prefix in the Prefix field.

      PreLen

         One octet unsigned integer containing the length in bits of
         the address prefix that follows.  A length of zero indicates
         a prefix that matches all addresses (the default
         destination); in this case the Prefix itself is zero octets).

      Prefix

         An address prefix encoded according to the Address
         Family field, whose length, in bits, was specified in the
         PreLen field, padded to a byte boundary.


3.2. Label distribution procedures

   Labels bound to Aggregated-prefix FECs MUST be distributed in ordered
   mode.  LSRs MUST NOT assign a NULL label value to an Aggregated-
   prefix FEC.






Swallow & Guichard           Standards Track                    [Page 7]


Internet Draft  draft-swallow-mpls-aggregated-fec-00.txt       July 2007


4. Algorithmically derived de-aggregation label

   In order to avoid having to distribute de-aggregation labels, they
   are algorithmically derived from the host address with the following
   procedure:

      The network mask is inverted and applied to mask off the
      high-order bits of the address.  The remaining bits are treated
      as an integer to which 16 is added.  This value represented as a
      20-bit integer becomes the label value.

   The value 16 is added in the algorithm in order to bypass the
   reserved label range.

   Issue:  This algorithm may not be appropriate for IPv6.



5. Security Considerations

   [to be written]



6. IANA Considerations

   [to be written]



7. References

7.1. Normative References

   [LDP]      Andersson, L. et al., "LDP Specification", RFC 3036,
              January 2001.

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












Swallow & Guichard           Standards Track                    [Page 8]


Internet Draft  draft-swallow-mpls-aggregated-fec-00.txt       July 2007


7.2. Informative References

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual
              Private Networks (VPNs)", RFC 4364, February 2006.




8. Authors' Addresses

      George Swallow
      Cisco Systems, Inc.
      1414 Massachusetts Ave.
      Boxborough, MA 01719

      Email:  swallow@cisco.com


      Jim Guichard
      Cisco Systems, Inc.
      1414 Massachusetts Ave
      Boxborough, MA 01719

      Email:  jguichar@cisco.com



Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement



Swallow & Guichard           Standards Track                    [Page 9]


Internet Draft  draft-swallow-mpls-aggregated-fec-00.txt       July 2007


   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.



Full Copyright Notice

   Copyright (C) The IETF Trust (2007).  This document is subject to the
   rights, licenses and restrictions contained in BCP 78, and except as
   set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

































Swallow & Guichard           Standards Track                   [Page 10]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/