Internet Draft                                           Tony Przygienda
                                                            prz@net4u.ch
                                                            Naiming Shen
                                                           Cisco Systems
                                                           Nischal Sheth
                                                        Juniper Networks
Expires: May 2008                                       November 5, 2007
Intended Status: Proposed Standard

              M-ISIS: Multi Topology (MT) Routing in IS-IS
               <draft-ietf-isis-wg-multi-topology-12.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


Copyright Notice

   Copyright (C) The IETF Trust (2007).


Abstract

    This document describes an optional mechanism within ISIS used today
    by many ISPs for IGP routing within their clouds. This document
    describes how to run within a single ISIS domain a set of
    independent IP topologies that we call Multi-Topologies (MTs).
    This MT extension can be used for variety of purposes such as an
    in-band management network ``on top'' of the original IGP topology,
    maintain separate IGP routing domains for isolated multicast or
    IPv6 islands within the backbone, or force a subset of an address
    space to follow a different topology.


Przygienda, Shen, Sheth      Expires May 2008                   [Page 1]


Internet Draft                   M-ISIS                    November 2007


1.  Introduction

    Maintaining multiple MTs for ISIS [ISO10589] [RFC1195] in a
    backwards-compatible manner necessitates several extensions to the
    packet encoding and additional SPF procedures.  The problem can
    be partitioned into forming of adjacencies, and advertising of
    prefixes and reachable intermediate systems within each topology.
    Having put all the necessary additional information in place, it
    must be properly used by MT capable SPF computation. The following
    sections describe each of the problems separately. To simplify the
    text, "standard" ISIS topology is defined to be MT ID #0 (zero).

1.1 Conventions Used in This Document

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

1.2 Definitions of Terms Used in This Document

    CSNP Complete Sequence Number Packet. Used to describe all the
         contents of a link state database of IS-IS.

    DIS  Designated Intermediate System. The intermediate system
         elected to advertise the pseudonode for a broadcast
         network.

    IIH  IS-IS Hello. Packets that are used to discover adjacent
         intermediate systems.

    LSP  Link State Packet. Packet generated by an intermediate
         system and lists adjacent systems, prefixes and other
         information.

    PSNP Partial Sequence Number Packet. Used to request information
         from an adjacent intermediate system's link state
         database.

    SPF  Shortest Path First. An algorithm that takes a database
         of nodes within a domain and builds a tree of connectivity
         along the shortest paths through the entire network.


2.  Maintaining MT Adjacencies

    Each adjacency formed MUST be classified as belonging to a set of
    MTs on the interface.  This is achieved by adding a new TLV into
    IIH packets that advertises which topologies the interface belongs
    to.  If MT #0 is the only MT on the interface, it is optional to
    advertise it in the new TLV. Thus not including such a TLV in the
    IIH implies MT ID #0 capability only. Through this exchange of MT


Przygienda, Shen, Sheth      Expires May 2008                   [Page 2]


Internet Draft                   M-ISIS                    November 2007


    capabilities, a router is able to advertise the IS TLVs in LSPs
    with common MT set over those adjacencies.

    In the case of adjacency contains multiple MTs on an interface, and
    if there exists overlapping IP address space among the topologies,
    additional mechanism MUST be used to resolve the topology identity
    of the incoming IP packets on the interface. See more discussion in
    section 8.2.2 of this document.

2.1.  Forming Adjacencies on Point-to-Point Interfaces

    Adjacencies on point-to-point interfaces are formed as usual with
    ISIS routers not implementing MT extensions.  If local router does
    not participate in certain MTs, it will not advertise those MTIDs
    in its IIHs and thus will not include that neighbor within it's
    LSPs. On the other hand, if a MTID is not detected in remote
    side's IIHs, the local router MUST NOT include that neighbor
    within its LSPs.  The local router SHOULD NOT form an adjacency if
    they don't have at least one common MT over the interface.

2.2.  Forming Adjacencies on Broadcast Interfaces

    On a LAN, all the routers on the LAN which implement the MT
    extension MAY advertise their MT capability TLV in their IIHs.
    If there is at least one adjacency on the LAN interface which
    belongs to this MT, the MT capable router MUST include the
    corresponding MT IS Reachable TLV in its LSP, otherwise it MAY
    include this MT IS Reachable TLV in its LSP if the LAN interface
    participates in this MT set.

    Two Routers on a LAN SHALL always establish adjacency regardless
    whether they have common MT or not. This is to ensure all
    the routers on the LAN can correctly elect the same DIS. The IS
    SHOULD NOT include the MT IS TLV in its LSP if none of the
    adjacencies on the LAN contains this MT.

    The DIS, CSNP and PSNP functions are not changed by MT extension.


3.  Advertising MT Reachable Intermediate Systems in LSPs

    A router MUST include within its LSPs in the Reachable Intermediate
    Systems TLVs only adjacent nodes that are participating in the
    corresponding topology and advertise such TLVs only if it
    participates itself in the corresponding topology.  Standard
    Reachable Intermediate Systems TLV is acting here as MT ID #0
    equivalent of the newly introduced MT Reachable Intermediate Systems
    TLV. A router MUST announce the MT IS TLV when there is at least
    one adjacency on the interface that belongs to this MT, otherwise
    it MAY announce the MT IS TLV of an adjacency for a given MT if this
    interface participates in the LAN.


Przygienda, Shen, Sheth      Expires May 2008                   [Page 3]


Internet Draft                   M-ISIS                    November 2007


    Since it is not possible to prevent a router that does not
    understand MT extensions from being responsible for generation of
    the according pseudo-node, it is not possible either to introduce
    special TLVs in the pseudo-node LSPs nor run distinct DIS elections
    per MT. Therefore, a generated pseudo-node LSP by DIS MUST contain
    in its IS Reachable TLV all nodes on the LAN as usual regardless
    of their MT capabilities. In other words, there is no change to the
    pseudo-node LSP construction.


4.  MTs and Overload, Partition and Attached Bits

    A router could for each of the MTs become potentially
    partitioned, overloaded and attached independently.  To prevent
    unnecessary complexity, MT extensions does not support MT based
    partition repair. The overload, partition and attached bits in LSP
    header only reflect the status of the default topology.

    Attached bit and overload bit are part of the MT TLV being
    distributed within a node's LSP fragment zero. Since each adjacency
    can belong to different MTs, it is possible that some MTs are L2
    attached, and others are not on the same router. The overload
    bit in the MT TLV can be used to signal the topology being
    overloaded. A MT based system is considered being overloaded if
    the overload bit in the MT is set.

    Route leaking between the levels SHOULD only be performed within
    the same MT.


5.  Advertising MT Specific IP Prefixes

    Each of the MTs commands its own address space so a new TLV is
    necessary for prefixes stored in MTs other than MT ID #0.  To
    make the encoding less confusing when same prefixes are present in
    multiple MTs and accelerate SPF per MT, rather than adding a sub-TLV
    in TE extensions, a new TLV is introduced for that purpose that
    closely follows TE encoding [LS01].


6.  MT SPF Computation

    Each MT MUST run its own instance of the decision process.
    The pseudo-node LSPs are used by all topologies during computation.
    Each non-default topology MAY have it's attached bit and overload
    bit set in the MT TLV. Reverse connectivity check within SPF MUST
    follow the according MT to assure the bi-directional reachability
    within the same MT.

    The results of each computation SHOULD be stored in a separate RIB
    in normal cases, otherwise overlapping addresses in different


Przygienda, Shen, Sheth      Expires May 2008                   [Page 4]


Internet Draft                   M-ISIS                    November 2007


    topologies could lead to undesirable routing behavior such as
    forwarding loops. The forwarding logic and configuration need to
    ensure the same MT is traversed from the source to the destination
    for packets. The nexthops derived from the MT SPF MUST belong to
    the adjacencies conforming to the same MT for correct forwarding.
    It is recommended for the administrators to ensure consistent
    configuration of all routers in the domain to prevent undesirable
    forwarding behavior.

    No attempt is made in this document to allow one topology to
    calculate routes using the routing information from another
    topology inside SPF. Even though it is possible to redistribute
    and leak routes from another IS-IS topology or from external
    sources, and the exact mechanism is beyond the scope of this
    document.


7.  Packet Encoding

    Three new TLVs are added to support MT extensions.  One of them is
    common for the LSPs and IIHs.  Encoding of Intermediate System TLV
    and IPv4 Reachable Prefixes is tied to traffic engineering
    extensions [LS01] to simplify the implementation effort. The main
    reasons we choose using new TLVs instead of using sub-TLVs inside
    existing TLV type-22 and type-135 are: In many cases,
    multi-topologies are non-congruent, using sub-TLV approach will
    not save LSP space; Many sub-TLVs are already being used in TLV
    type-22, and many more are being proposed while there is a maximum
    limit on the TLV size, from the existing TLVs; If traffic
    engineering or some other applications are being applied per
    topology level later, the new TLVs can automatically inherit the
    same attributes already defined for the "standard" IPv4 topology
    without going through long standard process to redefine them per
    topology.

7.1.  Multi-Topology TLV

    TLV number of this TLV is 229.  It contains one or more MTs
    the router is participating in the following structure:

      x  CODE - 229
      x  LENGTH - total length of the value field, it SHOULD be 2
                    times the number of MT components.
      x  VALUE - one or more 2-byte MT components, structured
                   as follows:
                                              No. of Octets
          +--------------------------------+
          |O |A |R |R |        MT ID       |      2
          +--------------------------------+

          Bit O represents the OVERLOAD bit for the MT (only valid


Przygienda, Shen, Sheth      Expires May 2008                   [Page 5]


Internet Draft                   M-ISIS                    November 2007


          in LSP fragment zero for MTs other than ID #0, otherwise
          SHOULD be set to 0 on transmission and ignored on receipt.)

          Bit A represents the ATTACH bit for the MT (only valid
          in LSP fragment zero for MTs other than ID #0, otherwise
          SHOULD be set to 0 on transmission and ignored on receipt.)

          Bits R are reserved, SHOULD be set to 0 on transmission
          and ignored on receipt.

          MT ID is a 12-bit field containing the ID of the topology
          being announced.

    This MT TLV can advertise up to 127 MTs and it can occur multiple
    times if needed within IIHs and LSP fragment zero.  The result MT
    set SHOULD be the union of all the MT TLV occurrence in the packet.
    Any other ISIS PDU occurrence of this TLV MUST be ignored. Lack

    of MT TLV in hellos and fragment zero LSP MUST be interpreted as
    participation of the advertising interface or router in
    MT ID #0 only. If a router advertises MT TLV, it has to advertise
    all the MTs it participates in, specifically including topology
    ID #0 also.

7.2.  MT Intermediate Systems TLV

    TLV number of this TLV is 222.  It is aligned with extended IS
    reachability TLV type 22 beside an additional two bytes in front at
    the beginning of the TLV.

      x  CODE - 222
      x  LENGTH - total length of the value field
      x  VALUE - 2-byte MT membership plus the format of extended IS
                 reachability TLV, structured as follows:

                                              No. of Octets
          +--------------------------------+
          |R |R |R |R |        MT ID       |      2
          +--------------------------------+
          | extended IS TLV format         |    11 - 253
          +--------------------------------+
          .                                .
          .                                .
          +--------------------------------+
          | extended IS TLV format         |    11 - 253
          +--------------------------------+

          Bits R are reserved, SHOULD be set to 0 on transmission
          and ignored on receipt.

          MT ID is a 12-bit field containing the non-zero MT ID of the


Przygienda, Shen, Sheth      Expires May 2008                   [Page 6]


Internet Draft                   M-ISIS                    November 2007


          topology being announced. The TLV MUST be ignored if the ID
          is zero. This is to ensure the consistent view of the standard
          unicast topology.

          After the 2-byte MT membership format, the MT IS content is
          in the same format as extended IS TLV, type 22 [LS01]. It
          can contain up to 23 neighbors of the same MT if no sub-TLVs
          are used.

    This TLV can occur multiple times.

7.3.  Multi-Topology Reachable IPv4 Prefixes TLV

    TLV number of this TLV is 235.  It is aligned with extended IP
    reachability TLV type 135 beside an additional two bytes in front.

      x  CODE - 235
      x  LENGTH - total length of the value field
      x  VALUE - 2-byte MT membership plus the format of extended
                 extended IP reachability TLV, structured as follows:

                                              No. of Octets
          +--------------------------------+
          |R |R |R |R |        MT ID       |      2
          +--------------------------------+
          | extended IP TLV format         |    5 - 253
          +--------------------------------+
          .                                .
          .                                .
          +--------------------------------+
          | extended IP TLV format         |    5 - 253
          +--------------------------------+

          Bits R are reserved, SHOULD be set to 0 on transmission
          and ignored on receipt.

          MT ID is a 12-bit field containing the non-zero ID of the
          topology being announced. The TLV MUST be ignored if the ID
          is zero. This is to ensure the consistent view of the standard
          unicast topology.

          After the 2-byte MT membership format, the MT IPv4 content
          is in the same format as extended IP reachability TLV,
          type 135 [LS01].

    This TLV can occur multiple times.


7.4.  Multi-Topology Reachable IPv6 Prefixes TLV

    TLV number of this TLV is 237.  It is aligned with IPv6 Reachability


Przygienda, Shen, Sheth      Expires May 2008                   [Page 7]


Internet Draft                   M-ISIS                    November 2007


    TLV type 236 beside an additional two bytes in front.

      x  CODE - 237
      x  LENGTH - total length of the value field
      x  VALUE - 2-byte MT membership plus the format of IPv6
                 Reachability TLV, structured as follows:

                                              No. of Octets
          +--------------------------------+
          |R |R |R |R |        MT ID       |      2
          +--------------------------------+
          | IPv6 Reachability format       |    6 - 253
          +--------------------------------+
          .                                .
          +--------------------------------+
          | IPv6 Reachability format       |    6 - 253
          +--------------------------------+

          Bits R are reserved, SHOULD be set to 0 on transmission
          and ignored on receipt.

          MT ID is a 12-bit field containing the ID of the topology
          being announced. The TLV MUST be ignored if the ID
          is zero.

          After the 2-byte MT membership format, the MT IPv6 context
          is in the same format as IPv6 Reachability TLV,
          type 236 [H01].

    This TLV can occur multiple times.


7.5.  Reserved MT ID Values

    Certain MT topologies are assigned to serve pre-determined purposes:

     -  MT ID #0:          Equivalent to the "standard" topology.
     -  MT ID #1:          Reserved for IPv4 in-band management
                           purposes.
     -  MT ID #2:          Reserved for IPv6 routing topology.
     -  MT ID #3:          Reserved for IPv4 multicast routing topology.
     -  MT ID #4:          Reserved for IPv6 multicast routing topology.
     -  MT ID #5:          Reserved for IPv6 in-band management
                           purposes.
     -  MT ID #6-#3995:    Reserved for IETF consensus.
     -  MT ID #3996-#4095: Reserved for development, experimental and
                           proprietary features [RFC3692].


8. MT IP Forwarding Considerations



Przygienda, Shen, Sheth      Expires May 2008                   [Page 8]


Internet Draft                   M-ISIS                    November 2007


    Using MT extension for ISIS routing can result in multiple RIBs
    on the system.  In this section we
    list some of the known considerations for IP forwarding in various
    MT scenario. Certain deployment scenarios presented here
    imply different trade-offs in terms of deployment difficulties
    and advantages obtained.

8.1. Each MT belong to a distinct address family

    In this case, each MT related routes are installed into a
    separate RIB. Multiple topologies can share the same ISIS interface
    on detecting the incoming packet address family. As an example,
    IPv4 and IPv6 can share the same interface without any further
    considerations under MT ISIS.

8.2. Some MTs belong to the same address family

8.2.1. Each interface belongs to one and only one MT

    In this case, MTs can be used to forward packets from the
    same address family, even with overlapping addresses. Since the
    MTs have their dedicated interfaces, and those interfaces can be
    associated with certain MT RIBs and FIBs.

8.2.2. Multiple MTs share an interface with overlapping addresses

    Some additional mechanism is needed to select the correct RIBs
    for the incoming IP packets to determine the correct RIB to make
    a forwarding decision. For example, if the topologies are
    QoS partitioned, then the DSCP bits in the IP packet header can
    be utilized to make the decision. Some IP header or even packet
    data information MAY be checked to make the forwarding table
    selection, such as source IP address in the header can be used
    to determine the desired forwarding behavior.

    This topic is not unique to IS-IS or even to Multi-topology, it
    is a local policy and configuration decision to make sure the
    inbound traffic uses the correct forwarding tables. For example,
    preferred customer packets are sent through a L2TP towards the
    high-bandwidth upstream provider, and other packets are sent
    through a different L2TP to a normal-bandwidth provider. Those
    mechanism are not part of the L2TP protocol specifications.

    The generic approach of packet to multiple MT RIB mapping over
    the same inbound interface is outside the scope of this document.

8.2.3. Multiple MTs share an interface with non-overlapping addresses

    When there is no overlap in the address space among all the MTs,
    strictly speaking the destination address space classifies the
    topology a packet belongs to. It is possible to install routes


Przygienda, Shen, Sheth      Expires May 2008                   [Page 9]


Internet Draft                   M-ISIS                    November 2007


    from different MTs into a shared RIB. As an example of such a
    deployment, a special ISIS topology can be setup for certain
    EBGP nexthop addresses.

8.3 Some MTs are not used for forwarding purpose

    MT in ISIS MAY be used even if the resulting RIB is not used for
    forwarding purposes. As an example, multicast RPF check can be
    performed on a different RIB than the standard unicast RIB albeit
    an entirely different RIB is used for the multicast forwarding.
    However, an incoming packet MUST be still clearly identified as
    belonging to a unique topology.


9. MT Network Management Considerations

    When multiple ISIS topologies exist within a domain, some of the
    routers can be configured to participate in a subset of the MTs
    in the network. This section discusses some of the options we
    have to enable operations or the network management stations to
    access those routers.

9.1. Create dedicated management topology to include all the nodes

    This approach is to setup a dedicated management topology or
    'in-band' management topology. This 'mgmt' topology will include
    all the routers need to be managed. The computed routes in the
    topology will be installed into the 'mgmt' RIB. In the condition
    of the 'mgmt' topology uses a set of non-overlapping address space
    with the default topology, those 'mgmt' routes can also be
    optionally installed into the default RIB.
    The advantages of duplicate 'mgmt' routes in both RIBs include:
    the network management utilities on the system does not have to be
    modified to use specific RIB other than the default RIB; the 'mgmt'
    topology can share the same link with the default topology if so
    designed.

9.2. Extend the default topology to all the nodes

    Even in the case default topology is not used on some of the nodes
    in the IP forwarding, we MAY want to extend the default topology
    to those nodes for the purpose of network management. Operators
    SHOULD set high cost on the links which belong to the extended
    portion of the default topology. This way the IP data traffic
    will not be forwarded through those nodes during network topology
    changes.


10.  Acknowledgments

    The authors would like to thank Andrew Partan, Dino Farinacci,


Przygienda, Shen, Sheth      Expires May 2008                  [Page 10]


Internet Draft                   M-ISIS                    November 2007


    Derek Yeung, Alex Zinin, Stefano Previdi, Heidi Ou, Steve Luong,
    Pekka Savola, Mike Shand, Shankar Vemulapalli and Les Ginsberg
    for the discussion, their review, comments and contributions to
    this document.


11.  Security Consideration

    ISIS security applies to the work presented.  No specific security
    issues with the proposed solutions are known. The authentication
    procedure for ISIS PDUs is the same regardless of MT information
    inside the ISIS PDUs.

    Note that an authentication mechanism, such as the one defined in
    [RFC3567] SHOULD be applied if there is high risk resulting
    from modification of multi-topology information.

    As described in section 8.2.2, multiple topologies share an
    interface in the same address space, some mechanism beyond
    IS-IS need to be used to select the right forwarding table
    for an inbound packet. A misconfiguration on the system or
    a packet with spoofed source address for example can lead to
    packet loss or unauthorized use of premium network resource.


12. IANA Considerations

    This document defines the following new IS-IS TLV types, which have
    already been reflected in the IANA IS-IS TLV code-point registry:

       Name                    Value

       MT-ISN                  222
       M-Topologies            229
       MT IP. Reach            235
       MT IPv6 IP. Reach       237

    IANA is requested to create a new registry, "IS-IS multi-topology ID
    values" with the assignment listed in Section 7.5 of this document
    and registration policies [RFC2434] for future assignments. The
    MT ID values range 6-3095 are allocated through Expert Review;
    values in the range of 3096-4095 are reserved for Private Use.
    In all cases, assigned values are to be registered with IANA.


13.  References

13.1. Normative References

    [ISO10589] ISO.  Intermediate System to Intermediate System Routing
               Exchange Protocol for Use in Conjunction with the


Przygienda, Shen, Sheth      Expires May 2008                  [Page 11]


Internet Draft                   M-ISIS                    November 2007


               Protocol for Providing the Connectionless-Mode Network
               Service. ISO 10589, 1992.

    [RFC1195]  R. Callon.  Use of OSI ISIS for Routing in TCP/IP and
               Dual Environments. RFC 1195, December 1990.

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

    [RFC3692]  Narten, T., "Assigning Experimental and Testing
               Numbers Considered Useful", BCP 82, RFC 3692, January
               2004.

    [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing
               an IANA Considerations Section in RFCs", BCP 26,
               RFC 2434, October 1998.


13.2. Informative References

    [RFC3567]  Li, T. and R. Atkinson, "Intermediate System to
               Intermediate System (IS-IS) Cryptographic
               Authentication", RFC 3567, July 2003.

    [LS01]     T. Li and H. Smit.  IS-IS Extensions for Traffic
               Engineering. RFC 3784,   May 2005.

    [H01]      C. Hopps. Routing IPv6 with IS-IS.
               draft-ietf-isis-ipv6-07.txt, October 2007.
               (work in progress)


14.  Authors' Addresses

    Tony Przygienda
    Z2 Sagl
    Via Rovello 32
    CH-6942 Savosa
    prz@net4u.ch

    Naiming Shen
    Cisco Systems
    225 West Tasman Drive
    San Jose, CA, 95134 USA
    naiming@cisco.com

    Nischal Sheth
    Juniper Networks
    1194 North Mathilda Avenue
    Sunnyvale, CA 94089 USA
    nsheth@juniper.net


Przygienda, Shen, Sheth      Expires May 2008                  [Page 12]


Internet Draft                   M-ISIS                    November 2007


Intellectual Property Statement

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

Copyright Statement

   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.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).








Przygienda, Shen, Sheth      Expires May 2008                  [Page 13]