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

Versions: 00 01 02

Internet Draft                                                 Feb 2006

   Network Working Group                                Joel M. Halpern
   Internet Draft
                                                           Manav Bhatia
                                                    Riverstone Networks
                                                             Paul Jakma
                                                       Sun Microsystems
   Expires: August 2006                               February 10, 2006

              Advertising Equal Cost Multipath routes in BGP


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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet draft will expire on August 2006

Copyright Notice

   Copyright (C) The Internet Society (2006).


   This document describes an extensible mechanism that will allow a BGP
   [BGP4] speaker to advertise ECMP routes for a destination to its
   peers. It uses an existing, Multi Hop Capability [M-HOP], to
   advertise multiple paths that it is using to its peers.

Halpern, Bhatia and Jakma                                      [Page 1]

Internet Draft                                                 Feb 2006

   The mechanism described in this document is only applicable to
   routers that have the ability to inject multiple routing entries in
   their forwarding table.

   Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [KEYWORDS]

Table of Contents

   1. Introduction...................................................2
   2. Some BGP ECMP Scenarios........................................3
   3. Requirements for the ECMP algorithm............................5
   4. ECMP Capability................................................6
   5. Operation when both peers are Multipath capable................6
   6. Advertisement of Multipath BGP routes..........................6
   7. Procedures for the Receiving Speaker...........................7
   8. Working with Non Multipath capable/EBGP peers..................7
   9. Configuring BGP ECMP support...................................9
   10. Working with Multipath capable IBGP peers.....................9
   11. Aggregation vis-à-vis Multi-Hop Solution.....................10
   12. Security Considerations......................................11
   13. Acknowledgements.............................................11
   14. IANA Considerations..........................................11
   15. Appendix A...................................................11
      15.1 Constructing AS_PATHs....................................11
      15.2 Advertising synthetic AS_PATHs...........................12
   16. References...................................................12
   17. Author's Addresses...........................................13
   18. Intellectual Property Notice.................................14
   19. Disclaimer of Validity.......................................14
   20. Copyright Statement..........................................14
   21. Acknowledgment...............................................14

1. Introduction

   Most of the current BGP implementations upon receiving multiple equal
   cost BGP routes from different peers can insert all of them (or a
   subset depending upon the local policies) in their forwarding table.
   This can be done to locally split the traffic across several paths.
   However, because BGP in its current state can only advertise one path
   to its peers, an implementation MUST choose from one of the best
   paths that it is using for the advertisement.

   This has implications for the BGP peers that receive such
   advertisements from ECMP capable BGP speakers. In the worst case it
   can lead to potential loops if the entire path information is not

Halpern, Bhatia and Jakma                                      [Page 2]

Internet Draft                                                 Feb 2006

   advertised to the peers. The best that can be currently done is to
   aggregate all the contributing paths and advertise the aggregated
   route. Doing this leads to a loss in the path length.

   This imposes a severe limitation on the kind of load balancing that a
   BGP peer can do.

   The use of BGP ECMP routes is most prevalent inside an AS to identify
   its local BGP routes that represent load balanced links. This is
   useful for applications that want to use the BGP protocol as a
   mechanism for propagating this information for load balancing across
   multiple IBGP paths.

   This document refers to all the candidate paths that remain after the
   tie breaking procedure, described in sec., reaches step (f)
   as "ECMP BGP paths/routes". It should be noted that these paths shall
   have the same AS_PATH length, though the individual AS_PATH segments
   could differ.

   Advertising individual BGP ECMP paths with different NEXT_HOPs holds
   value in IBGP scenarios, as each IBGP peer can reach the NEXT_HOP on
   its own.

   However in case of EBGP, individual BGP paths MAY only be advertised
   if the contributing routers are on the same subnet. If the peers
   don’t lie on the same subnet, then information about each individual
   NEXT_HOP is not useful. This is because (i) the receiving EBGP peer
   is not be aware of the NEXT_HOP information inside some other ASes
   and, (ii) the EBGP speaker always resets the NEXT_HOP to itself when
   advertising routes. Thus, individual BGP ECMP paths for a destination
   are only advertised to IBGP peers or EBGP peers that lie on the same
   subnet. In other cases, only one path is announced which is an
   “aggregate” of all the individual equal cost paths for that

   However, care must be taken to ensure that the AS_PATH length in this
   aggregated path is retained and enough information is there in the
   AS_PATH to enable the receiving peer (and the downstream peers) to
   detect AS loops.

2. Some BGP ECMP Scenarios

   o Load Splitting when receiving BGP routes

Halpern, Bhatia and Jakma                                      [Page 3]

Internet Draft                                                 Feb 2006

   A (AS X)
        C (AS Y)
   B (AS Z)

   A, B and C are BGP speakers in AS X, Y and Z respectively.

   Assume that C is peered up with similar sized ISPs A and B and
   accepts entire Internet feed from each one of these. It is common in
   such scenarios for the ISP C to receive multiple routes of equal cost
   from both A and B. Ordinarily, C can use only one "best" route learnt
   from either of A or B. Configuring C for load balancing  involves a
   lot of prepending, modifying routes, splitting prefixes received from
   A and B, etc. Even then, it is difficult to have a 50/50 split across
   A and B as the load can only be statically split. The best and the
   most obvious solution is to let C install ECMP BGP routes in its FIB
   and to advertise information about all these ECMP BGP routes to its
   downstream peers, in a manner that lets each one of them run its loop
   detection algorithm.

   o Load Splitting when advertising BGP routes.

      / \
     /   \__
    /     \
   A(W)  D(Z)
    \    _/
     \   /
      \ /

   A, B, C and D are BGP speakers in AS W, X, Y and Z respectively.
   The dashed lines show EBGP peering.

   Scenario 1: Traditional BGP without ECMP capabilities

   Assume that A has a block of that it needs to advertise
   to both B and C. For the purpose of load balancing it splits this
   block into two smaller blocks of and and
   advertises each of these to B and C. Router A somehow needs to ensure
   that one block is more preferred in B and the other in C. This can be

Halpern, Bhatia and Jakma                                      [Page 4]

Internet Draft                                                 Feb 2006

   done by configuring policies that can prepend AS numbers, MEDs, etc.
   when advertising the BGP route associated with these prefixes. Say, is prepended with AS numbers when advertised to B and the when advertised to C. This ensures that all the traffic
   is split between B and C, as this is what is advertised to router D.
   The problems with this approach are:

   [1] Number of routes advertised increase.
   [2] Entries in FIB increase.
   [3] Complex policies need to be implemented at A to ensure that
   incoming traffic is balanced.
   [4] Load balancing is static and cannot ensure 50/50 split.

   Scenario 2: BGP with ECMP capabilities support

   Router A now does not need to split the original block of
   into two smaller blocks. It can advertise to both B and
   C. With B and C equidistant from D, the latter will insert BGP
   multipath route for with NEXT_HOPs as B and C and will
   advertise this to its downstream peers. Whatever traffic comes to D
   will be split across routers B and C. The load balancing this way is
   dynamic and not static. Entries in the FIB remain under control and
   Router A need not implement those complex policies. Router D needs to
   advertise information about the paths it is using to its downstream
   peers, so that they can run the loop detection algorithm.

   o Suboptimal Routing in Route Reflector clients

   Route Reflection can result in suboptimal routing due to the client
   not having full visibility to all the BGP paths in the AS. This is
   because the RR selects the best path and reflects only that best path
   to its clients. In case the RR has equal cost BGP routes, then it
   shall select the one based on the lower Router ID. As a result, the
   clients do not receive the full view of the available paths, or
   atleast the paths that are equidistant from the RR. This is bad, as
   this can result in suboptimal routing from the client's perspective.
   A client may have selected a different best path if more paths had
   been made visible to it. With BGP ECMP, the RR can advertise all the
   equal cost BGP routes that it has to its client, giving the client
   more options to choose from.

   The extensions proposed in this draft provide provision for the RR to
   reflect all the routes to its clients.

3. Requirements for the ECMP algorithm

   (a)  An ECMP capable peer must be able to advertise each individual
        BGP path to other ECMP capable IBGP peers.

Halpern, Bhatia and Jakma                                      [Page 5]

Internet Draft                                                 Feb 2006

   (b)  When advertising routes to non ECMP capable peers it must
        preserve as much of the AS Path structure as possible. This
        includes, the individual AS elements and the path length.

   We in this document propose an algorithm to advertise BGP ECMP
   routes, to both routers capable of ECMP and the ones without, so as
   to honor each of the requirements mentioned above.

4. ECMP Capability

   A router that wishes to express its capability to advertise ECMP
   routes uses the multi-hop capability [M-HOP].

   We define a new bit, ECMP bit, in the bitmask of flags. This is set
   if the router intends to install ECMP routes.

               | Bit:  | 7 | 6 | 5 | 4 | 3 | 2 | 1  | 0  |
               | flag: | R | R | R | R | R | R |ECMP| AE |

   ECMP and AE flags are mutually exclusive and both of them MUST not be
   set together.

   By advertising the Multi-hop capability to a peer with the ECMP bit
   set (multipath capable), the BGP Speaker conveys to its peer that the
   speaker is capable of receiving and properly handling the BGP ECMP
   updates from that peer.

5. Operation when both peers are Multipath capable

   In the following sections, "Local speaker" refers to a router which
   is advertising the BGP multipath routes, and the "Receiving Speaker"
   refers to a router that peers with the former to accept multiple BGP
   routes for a destination.

   Consider that the capability with the proper flags has been exchanged
   between the Local speaker and the Receiving speaker, and a BGP
   session between them is established. The following sections detail
   the procedures that shall be followed by the Local speaker as well as
   the Receiving speaker once the capability has been exchanged, and the
   local speaker wants to advertise some BGP multipath routes.

6. Advertisement of Multipath BGP routes

   To advertise BGP ECMP paths, the speaker uses MULTIPLE_HOP path
   attribute. Refer to [M-HOP] for details regarding how this path
   attribute is used.

Halpern, Bhatia and Jakma                                      [Page 6]

Internet Draft                                                 Feb 2006

7. Procedures for the Receiving Speaker

   The Receiving Speaker upon receiving the MULTIPLE_HOP attribute will
   understand that the Local Speaker has advertised multipath BGP
   routes. In a single UPDATE message all the prefixes will have
   identical attributes, except for the next-hops, which will be carried
   in the MULTIPLE_HOP attribute.

   It will run the modified decision process as explained in the Section
   1 and depending upon the result will either

   - inject multiple routes into Local-RIB and advertise multiple paths
     to its peers
   - inject a single route which has better path attributes than the
     other routes that it has just received.

   If the Receiving Peer receives some withdrawn routes along with the
   other path attributes and MULTIPLE_HOP attribute then it shall
   understand that some of the previously advertised multipath BGP
   routes have been removed and an implementation MUST proceed with
   removing all such paths.

8. Working with Non Multipath capable/EBGP peers

   This section discusses how BGP ECMP routes are advertised to non
   multipath capable routers or EBGP peers lying on different subnets.
   This is relevant only when the local speaker has installed BGP ECMP
   routes in its FIB and wants to convey this information to other peers
   that are not capable of understanding these capabilities.

   At this point the local speaker needs to aggregate this information
   and it can follow any algorithm that preserves as much of the
   available AS path structure as possible.

   A multipath capable speaker that has installed multiple BGP paths in
   its forwarding table MUST follow an algorithm to advertise the
   AS_PATH for each one of these routes in a manner that makes it
   possible for the downstream peers to run the AS Path loop detection
   algorithm. However, the algorithm MUST ensure that the AS_PATH length
   remains unaltered.

   There can exist multiple ways to do the above and we recommend one
   such algorithm which preserves most of the AS path structure and

   When crossing the multipath capable boundary to non-multipath
   capable, the speaker MUST send out a synthetic AS_PATH to the latter,

Halpern, Bhatia and Jakma                                      [Page 7]

Internet Draft                                                 Feb 2006

   where each element of the synthetic AS_PATH is an AS SET, built with
   the AS values corresponding to each segment in each contributing
   AS_PATH. This is possible since each of the contributing AS_PATHs are
   of the same length.

   The above procedure is described as a pseudo code. Note that the
   pseudo-code shown was chosen for clarity, not efficiency. It is not
   intended to specify any particular implementation. BGP
   implementations MAY use any algorithm which produces the same results
   as those described here.

   Given two AS_PATHs X and Y, each with N number of segments, which we
   wish to merge into a new combined AS_PATH, Z of N number of segments:

   Expand every AS_SEQUENCE segment in X and Y which contains multiple
   AS values into single-valued segments, such that the number of
   segments is equivalent to the path length, with order preserved.

       for every segment, n, from 0 to N
         create a segment Z(n) of type AS_SET
         for every AS value in segments X(n) and Y(n)
           add the AS value into Z(n)

   Resulting AS_PATH Z will consist of n AS_SETs, each AS_SET segment
   having all AS values in segments X(n) and Y(n).

   To cite an example, consider a BGP speaker (say in AS A1) having the
   following paths for a destination D1:

      Path 1:
      AS_PATH "a b c", Origin IGP, MED 10, NEXT_HOP N1

      Path 2:
      AS_PATH "x y z", Origin IGP, MED 20, NEXT_HOP N2

   It inserts these two paths in its forwarding table, and announces the
   following to its non-ecmp capable peer:

        AS_SET (a,x)
        AS_SET (b,y)
        AS_SET (c,z)
      Origin IGP, MED 10, NEXT_HOP [N1 or N2]

   The AS_PATH constructed for advertisement to an EBGP peer is

        AS_SEQUENCE "A1"
        AS_SET (a,x)

Halpern, Bhatia and Jakma                                      [Page 8]

Internet Draft                                                 Feb 2006

        AS_SET (b,y)
        AS_SET (c,z)

   Refer to Appendix A for more complex AS_PATH scenarios.

   The beauty of this new AS_PATH structure is that it retains the
   AS_PATH length of the original contributing paths and also retains
   enough AS information for the receiving peer to do loop prevention.

   For instance, if the router that has been used in the above example
   is peered up with another router R2 in AS "c", then R2 will reject
   all UPDATEs that have AS "c" in the AS_PATH.

   The Multipath capable router when advertising routes to a non-
   multipath capable IBGP peer can pick up any one of the NEXT_HOPs from
   the available list. This will not create any problems because this
   NEXT_HOP will actually fall within the AS_PATH set-sequence that is
   being advertised. For EBGP peers, the ECMP capable router, will as
   usual, put itself as the NEXT_HOP.

9. Configuring BGP ECMP support

   An implementation MUST provide a configuration option to set and
   unset this feature.

   The administrator should ensure that the maximum number of multipath
   routes that all the routers install in their FIB, remains consistent
   inside an AS.

10. Working with Multipath capable IBGP peers

   This section explains as to how ECMP feature will work in the normal

   Assume that the two IBGP speakers A and B exchange this capability.
   Consider a case where A receives multiple updates for NLRI N' with
   Nexthops N0, .. Ni, .. Nm. Say it runs its decision process and finds
   that routes with the Nexthops Nj, Nk and Nl are equal and that it
   needs to advertise all three of them to B. Also assume that Nj and Nk
   share the same path attributes (Origin, AS Path, Local Pref, etc).

   A makes an UPDATE message and uses the MULTIPLE_HOP path attribute.
   It puts the AFI, number of next-hops as 2, length of the first next-
   hop (Nj), network address of Nj, length of Nk and the network address
   of Nk.

   When this UPDATE message is received by B, it looks at the
   MULTIPLE_HOP path attribute and understands that there are multiple

Halpern, Bhatia and Jakma                                      [Page 9]

Internet Draft                                                 Feb 2006

   routes to reach N'. It inserts two routes for N' with the next-hops
   as Nj and Nk.

   A also needs to announce N' with some other path attributes and the
   next-hop Nl. It makes an UPDATE message, puts the path attributes,
   and puts the MULTIPLE_HOP path attribute. It fills the AFI, number of
   next-hops as 1, length of the first next-hop Nl and the network
   address of Nl. This UPDATE message is sent to B.

   When B receives this UPDATE message it knows that this is not an
   implicit WITHDRAW from N' as it comes with the MULTIPLE_HOP path
   attribute. It simply appends this new route in its BGP database, runs
   the decision process, and proceeds as normal.

   Assume that at some point later, A needs to withdraw the route
   associated with the tuple [N', Nk]. It makes an UPDATE message, puts
   N' in the unfeasible routes and inserts path attributes and the
   MULTIPLE_HOP path attribute, keeping the next-hop inside as Nk.

   When B receives this UPDATE message it understands that A now wants
   to remove a route associated with N'. It looks at MULTIPLE_HOP and
   finds the next-hop as Nk. It thus removes, only the route associated
   with Nk.

11. Aggregation vis-à-vis Multi-Hop Solution

   Another approach to do ECMP is via advertising all the contributing
   routes through aggregation. In this approach any router that installs
   multiple BGP routes in its FIB can aggregate the contributing routes
   and advertise the aggregated route to its peers. The problem with
   this approach is that the AS_PATH length is not preserved.

   A clever implementation could prepend its own AS the required number
   of times to preserve the path length when advertising routes to EBGP
   peers, but this will not work when advertising routes to IBGP peers.

   Moreover, lumping everything in one AS_SET hides information and
   makes it harder for the downstream peers to make out as to what is
   actually happening. Our method of constructing the synthetic AS_PATH
   is somewhat complex but preserves maximum information and is regular
   expression friendly.

   Another problem with aggregating the information at the router that
   is doing ECMP is that this router cannot advertise individual
   contributing routes to its other ECMP capable peers. Advertising
   individual routes is desirable in some cases as different BGP peers
   make their path decisions based on their local policies and
   advertising them just one aggregated route makes it impossible for
   them to do so.

Halpern, Bhatia and Jakma                                      [Page 10]

Internet Draft                                                 Feb 2006

   Moreover, by providing them with the NEXT_HOP information each peer
   can choose its best IGP route to reach those NEXT_HOPs.

   Last but not the least, putting all the ASes inside one set can cause
   the SET to overflow. In that case, the path length would increase by

12. Security Considerations

   This extension to BGP does not change the underlying security issues
   inherent in the existing BGP.

13. Acknowledgements

   The authors would like to thank Tony Li and Curtis Villamizar for
   their valuable comments and suggestions.

14. IANA Considerations

   This document uses an attribute type to indicate additional next-hops
   for the BGP paths. This must be assigned by IANA as per RFC 2842.

15. Appendix A

15.1 Constructing AS_PATHs

   This section deals with some scenarios that could occur. Consider
   that ecmp capable Router R1 has received multiple paths for a
   destination D1 and it is connected to a non-ecmp capable/EBGP router
   R2. R1 thus cannot use the MULTIPLE_HOP attribute to announce these

   [Scenario 1]

   Say, R1 has the following BGP paths that it installs in its FIB.

   Path 1: AS_PATH: AS_SEQ "a b", AS_SET "p1 p2", AS_SET "p3 p4",
           NEXT_HOP N1

   Path 2: AS_PATH: AS_SEQ "x y", AS_SET "q1 q2 q3", AS_SET "q4",
           NEXT_HOP N2

   It is to be noted in this case when R1 runs its decision process, AS
   Path lengths are the same because when counting this number, an
   AS_SET counts as 1, no matter how many ASes are in the SET.

   The AS_PATH that R1 thus constructs when announcing the UPDATE to R2
   (assuming R2 is an IBGP peer) is:

Halpern, Bhatia and Jakma                                      [Page 11]

Internet Draft                                                 Feb 2006

   AS_PATH: AS_SET "a x",
            AS_SET "b y",
            AS_SET "p1 p2 q1 q2 q3",
            AS_SET "p3 p4 q4"

   It will create a new AS_SEQ segment if R2 is an EBGP peer.

   [Scenario 2]

   Say, R1 has the following BGP paths that it installs in its FIB.

   Path 1: AS_PATH: AS_SEQ "a b c", AS_SET "p1 p2", NEXT_HOP N1

   Path 2: AS_PATH: AS_SEQ "x y", AS_SET "q1 q2 q3", AS_SET "q4",
           NEXT_HOP N2

   The AS_PATH that R1 thus constructs when announcing the UPDATE to R2
   (assuming R2 is an IBGP peer) is:

   AS_PATH: AS_SET "a x"
            AS_SET "b y"
            AS_SET "c q1 q2 q3"
            AS_SET "p1 p2 q4"

15.2 Advertising synthetic AS_PATHs

   This section discusses some optimizations/cleanups that can be done
   by a BGP speaker when constructing the synthetic AS_PATH, to
   advertise to a non-ecmp capable or an EBGP peer.

   X(n) and Y(n) are two AS_PATHs, each with N number of segments, which
   will be merged into a new combined synthetic AS_PATH, Z of N number
   of segments:

   - If X(n) and Y(n) are both of type AS_SEQUENCE and contain the same
   value, the type of Z(n) MUST be set to AS_SEQUENCE, the value being
   the single as value concerned common to X(n) and Y(n).

   - Duplicate AS values MUST be removed from Z(n) once all values have
   been added to it, if the implementation has not already discarded
   duplicate values while iterating through X(n) and Y(n) when
   constructing segment Z(n)

16. References

   [M-HOP]   Bhatia, M., Halpern, J. and Jakma, P., “Advertising
             Multiple Nexthop Routes in BGP”,

Halpern, Bhatia and Jakma                                      [Page 12]

Internet Draft                                                 Feb 2006

             draft-bhatia-idr-multiple-hops-00.txt, February 2006,
             Work in Progress

   [BGP4]    Rekhter, Y., Li, T. and Hares, S.,  "A Border Gateway
             Protocol 4 (BGP-4)", RFC 4271, March 1995

   [BGP-CAP]  Chandra, R. and J. Scudder, "Capabilities Advertisement
              with BGP-4", RFC 3392, November 2002

   [MED]     D. McPherson, V, Gill, D. Walton, and A. Retana, "Border
             Gateway Protocol (BGP) Persistent Route Oscillation
             Condition", RFC 3345, August 2002.

   [BGP-IPv6]Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol
             Extensions for IPv6 Inter-Domain Routing", RFC 2545, March

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

   [AFI]     http://www.iana.org/assignments/address-family-numbers

   [SAFI]    http://www.iana.org/assignments/safi-namespace

   [CONFED]   McPherson, D., Scudder, J., and P. Traina, "Autonomous
              System Confederations for BGP",
              draft-ietf-idr-rfc3065bis-05 (work in progress),
              October 2005.

   [MPBGP]   Bates, T., R. Chandra, D. Katz, and Y. Rekhter,
             Multiprotocol Extension for BGP-4", RFC 2858, June 2000.

17. Author's Addresses

   Joel M. Halpern

   Email: joel@stevecrocker.com

   Manav Bhatia
   Riverstone Networks, Inc.

   Email: manav@riverstonenet.com

   Paul Jakma
   Sun Microsystems

   Email: paul.jakma@sun.com

Halpern, Bhatia and Jakma                                      [Page 13]

Internet Draft                                                 Feb 2006

18. Intellectual Property Notice

   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

   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
   this standard.  Please address the information to the IETF at ietf-

19. Disclaimer of Validity

   This document and the information contained herein are provided on an

20. Copyright Statement

   Copyright (C) The Internet Society (2006).  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.

21. Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Halpern, Bhatia and Jakma                                      [Page 14]

Internet Draft                                                 Feb 2006

Halpern, Bhatia and Jakma                                      [Page 15]

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