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

Versions: 00                                                            
Network Working Group                            Turner S.,Staegemeir B.
INTERNET DRAFT                                         SITA / Equant R&D
Expires September 1998                                        March 1998



          Differentiated Services over Symmetric NHRP Shortcuts
                   <draft-turner-diff-nhrp-00.txt>


Status of this Memo

   This document is an Internet-Draft.  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. Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time. It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a "working
   draft" or "work in progress".

   Please check the 1id-abstracts.txt listing contained in the internet-
   drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
   nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
   current status of any Internet Draft.


Abstract

   There is a need, for relatively simple and scaleable methods of
   providing  differentiated classes of service for IP traffic over
   various WAN media, to support different types of applications and
   specific business requirements. The Differentiated Services approach
   to providing quality of service (QoS) in Networks, employs a small,
   well-defined set of building blocks from which a variety of services
   may be built. A small bit-pattern in each packet in the IPv4 "TOS
   octet" or in the IPv6 "Traffic Class octet" is used to mark a  packet
   to receive a differentiated forwarding treatment or per-hop behavior
   at each network node. IETF Working Groups will standardize a common
   layout for both octets, called the "DS byte" superseding the IPv4 TOS
   octet definitions or RFC 1349 [1].

   The goal of this contribution is to suggest how the Next Hop
   Resolution Protocol (NHRP) may be extended and deployed in
   conjunction with the IP ToS octet (DS-Byte) to create both
   differentiated forwarding and differentiated class of service over
   an NBMA network such as ATM or Frame-Relay.







Turner, Staegemeir                                              [Page 1]


INTERNET DRAFT      Differentiated Services with NHRP         March 1998


   In the proposed solution, any SVC created between the same two points
   in an NBMA network will be used bi-directionally by traffic with the
   same class of service.  This is achieved by extending the scope of
   the existing NHRP protocol to include QoS information in the
   extensions part of both the NHRP resolution request and resolution
   reply, and by implementing a NBMA addressing scheme that dynamically
   maps CoS, to subaddresses that are unique within the NBMA network.

   The proposal is compliant with the NHRP specifications, and every
   effort is made by the proposal to build on the work currently
   underway within the IETF that is attempting to standardize on the
   use of the ToS octet (DS-byte) within the IP datagram.


1. NHRP Default Operation

   Within the scope of existing definitions [2], NHRP shortcuts may be
   created  between hosts, or ingress and egress routers at the edges of
   an NBMA network, with NHRP cache entries mapping remote layer 3
   prefixes (IP hosts, subnets or BGP next-hops) onto SVCs.  These
   cache entries may only be added after specific datagrams matching
   defined trigger criteria send an NHRP resolution request, and when
   that NHRP request is successfully returned. If in the NHRP
   resolution reply, the remote NBMA subaddress of the NHS maps to  an
   existing SVC that directly interconnects NHC and NHS, then the best
   match prefix in the forwarding table, that allowed the initial
   forwarding of the datagram over the default path, is typically
   added to the NHRP cache, and is mapped onto the existing SVC.  This
   means that all traffic flows between the same pair of ingress and
   egress points whose L3 destination address is mapped by the NHRP
   cache, will be merged onto the same NHRP shortcut.

   This default behaviour is very useful, particularly for network
   bootstrapping and for traffic engineering purposes, in order to
   minimize the number of routed hops and to reduce congestion in the
   core of the IP  network.


2. Extension of NHRP for Differentiated Forwarding

   The current applicability of NHRP severely limits the possibilities
   to use NHRP as a mechanism, or as part of a mechanism, to create
   Differentiated Classes-of-Service (CoS) across an NBMA network.  This
   is because the NHRP cache entries that indicate whether a shortcut
   should be used or not, are based on layer 3 prefixes, and although a
   delay sensitive application may in fact trigger the shortcut SVC,
   once created, this shortcut will be used by all traffic whose L3
   destination is included in the cache.  This in turn means that all
   traffic with a mixture of classes of service will be competing for
   resources over the same forwarding path, unless a mechanism is found
   which allows multiple shortcuts, and where path selection is based on
   the class of service information in the traffic flows.

Turner, Staegemeir                                              [Page 2]


INTERNET DRAFT      Differentiated Services with NHRP         March 1998


   However, using multiple SVCs between the same ingress and egress pair
   is problematic for two main reasons :

   i)  You need to introduce an additional element to the trigger
       criteria that specifies whether to use an existing SVC or not.

   ii) If another SVC is created for a specific policy at one end, in
       order to use this SVC in full duplex mode, both the policy and
       the mapping to an SVC must be known and synchronized at each end.

   Problem (i) is not insurmountable, but the corresponding changes to
   the NHRP cache structure may make it difficult to implement rapid
   packet forwarding over the correct SVC.

   Problem (ii) is more difficult, and requires the introduction of
   either a "central policy control point" ("one more server") and
   out-of-band synchronisation, or using a new "protocol" that allows
   end-to-end in-band correlation of layer 3 information with SVCs. This
   is definitely a non-trivial problem!

   A compromise is suggested to permit multiple SVCs between the same
   ingress  and egress points, and to allow both differentiated
   forwarding and differentiated class of service.

   The primary purpose of this strategy is to allow the creation of
   shortcuts,  and through the use of differentiated forwarding signaled
   by the ToS byte in IP datagrams, to prevent "low class" traffic
   mixing with "high class" traffic. Thus we create more performance
   determinacy.


3. Per Class-of-Service Shortcuts

   The proposal has three components:

   i)   A simple way to map an IP packet with a specific Class of
        Service information in the DS-byte to a corresponding SVC with
        an appropriate layer 2 traffic class.  The number of possible
        SVCs between the same source and destination prefix is
        therefore limited to the number of relevant DS-byte encodings,
        e.g. as defined in RFC 1349.  This does not imply that each
        defined CoS always maps onto a unique SVC, since different CoS
        may be grouped and mapped onto a shared SVC.

   ii)  The local association or mapping by Next Hop Resolution Clients
        (NHC) and Next Hop Resolution Servers (NHS), between a single
        class of service or a group of classes of service, and a unique
        NBMA subaddress.





Turner, Staegemeir                                              [Page 3]


INTERNET DRAFT      Differentiated Services with NHRP         March 1998


   iii) A protocol extension to ensure that all SVC based shortcuts are
        used in both directions.  This avoids the protocol and
        processing overhead for SVC creation in the reverse direction,
        and eliminates any additional set up delay and potential
        performance problems caused by asymmetric paths.

   The proposed "CoS enabled NHRP" works in the following way :

   i)   An NHRP request policy is directly associated with the IP ToS
        byte or specific elements in it.  An obvious example would be
        triggers based on the four precedence bits and its eight defined
        classes of services in RFC 1349.

   ii)  This policy should be consistently defined through NHRP
       "triggers" on all NHCs in the NBMA network.

   iii) Each NHC and NHS makes a local association between a Class of
        Service, identified by the ToS byte, and a globally unique NBMA
        subaddress.  This NBMA subaddress may be formed by appending or
        including a locally managed addressing element termed the "CoS
        designator", to the globally known and unique NBMA subaddress.
        e.g. In the case of a given router or host connected to an ATM
        network, each CoS is mapped to a specific value of selector byte
        that is then appended to the same 13 byte prefix and 6 byte
        ESI, to form a set of unique NSAPs.  Each NSAP thus globally
        identifies the NHS or NHC, and provides local significance as
        to the CoS assigned to each SVC shortcut. This association
        should be dynamically mapped according to the local
        implementation and means that the number of NBMA addresses or
        subaddresses per NHRP station must be greater than or equal to
        the number of CoS available across the NBMA subnetwork.

   iv)  When an NHRP client forwards a datagram into the NBMA cloud with
        a ToS byte that matches the trigger policy, an NHRP resolution
        request is created and sent. (It is assumed that no SVC
        shortcuts exist).  This NHRP request contains the ToS byte in
        the IP packet that triggered it, and is copied into the
        Extensions part of the NHRP resolution request.

   v)   When the NHRP request is received by the NHS at the egress point
        of the NBMA network, the ToS extension is examined, and the NBMA
        address returned in the reply is specific to that ToS.  i.e. the
        CoS designator that is locally associated with the value in the
        ToS extension is included in the NBMA address returned in the
        NHRP resolution reply.








Turner, Staegemeir                                              [Page 4]


INTERNET DRAFT      Differentiated Services with NHRP         March 1998


   vi)  When the NHRP reply is received by the NHC that triggered the
        initial request, an NHRP cache entry is created that maps the L3
        reachability information associated with the destination to the
        NBMA address contained in the resolution reply.  This NHRP cache
        entry is now extended to include the ToS information sent in the
        resolution request and suqsequently returned in the resolution
        reply.  An SVC to the remote NHS for this CoS can be created
        immediately or on receipt of a subsequent packet that matches
        the cached information.  The time at which the SVC is created
        and any L2 QoS related signaling  parameters are implementation
        specific.)

vii) Subsequent packets sent by the NHC are now compared to the NHRP
     cache entry in terms of destination IP address and the ToS byte.

   Now we distinguish three cases :

     i)    If a match is found on both conditions, then the packet is
           forwarded over the associated SVC.

     ii)   If a match is not found, and the QoS information in the
           packet header matches the trigger policy, then a new NHRP
           request is sent out as described previously.  When the reply
           is received and both destination NBMA address and ToS
           information is the same as an existing NBMA address/ToS pair,
           then the destination IP prefix is added to the NHRP cache,
           and the entry is mapped to the existing SVC.

     iii)  In the case of (ii), if the reply contains an NBMA address
           /ToS pair that does not map to an existing NHRP cache entry,
           then a new SVC is requested to the NBMA subaddress contained
           in the reply, and a new cache entry created as before.

     viii) In the reverse path, i.e. when the roles of NHC and NHS are
           reversed, an identical process is followed.  In this case,
           since an NHS should consistently return an NBMA subaddress
           that maps to a given CoS or group of CoS, then it is
           straightforward to determine if an SVC with the given CoS
           already exists, even if the SVC was remotely initiated.


4. Full Duplex Mode of Operation and Asymetric shortcut avoidance

   To avoid two SVCs with the same CoS being used unidirectionally
   between the same pair of NHRP stations, the following simple
   algorithm is proposed.

   When an NHRP resolution request is received by the NHS, a lookup is
   performed that keys on the source NBMA subaddress without CoS
   designator i.e. without the selector in the ATM case.



Turner, Staegemeir                                              [Page 5]


INTERNET DRAFT      Differentiated Services with NHRP         March 1998


   If no match is found, then continue as described previously.

   If a match is found, extract the requested CoS in the extensions part
   of the NHRP Resolution request and:

   i)   If neither the CoS nor the CoS designator from the NHRP
        resolution request are found in the CoS mapping table, then
        continue.

   ii)  If both the CoS and the CoS designator are found in the table,
        and they are mapped together, then continue.

   iii) If the CoS is found but it maps to a different CoS designator,
        then send a Resolution Reply with a NAK code of 4
        "Administratively Prohibited"

   iv)  If the CoS designator is found but it maps to a different CoS,
        then send a Resolution Reply with a NAK code of 4,
        "Administratively Prohibited"

When a resolution reply is received by the NHC, then do the following:

   i)   If NAK is received, then abort all attempts to include L3
        destination in NHRP cache.

   ii)  If the reply is valid, but the Compulsory bit is clear, assume
        CoS 0, i.e. shortcut forwarding over single SVC only to NHS.
        (see below)

   iii) If the reply is valid, and the Compulsory bit is set, then:

     a) Perform a lookup based on the source NBMA subaddress without
        CoS designator i.e. without the selector in the ATM case.

     b) If neither the CoS nor the CoS designator from the NHRP
        resolution request are found in the CoS mapping table, then
        continue.

     c) If both the CoS and the CoS designator are found in the table,
        and they are mapped together, then continue.

     d) If the CoS is found but it maps to a different CoS designator,
        then abort all attempts to include L3 destination in NHRP cache.

     e) If the CoS designator is found but it maps to a different CoS,
        then abort all attempts to include L3 destination in NHRP cache.







Turner, Staegemeir                                              [Page 6]


INTERNET DRAFT      Differentiated Services with NHRP         March 1998


5. Backwards compatibility with existing NHRP Implementations

   The "Compulsory" bit should be left clear in the NHRP resolution
   request to allow backwards compatibility with existing NHSs. If the
   egress router understands the extension and acts upon it, i.e. is
   performing CoS mapping, then this C bit should be set to 1 in the
   reply. This will allow the requestor to know whether to perform the
   asymmetric checking or not, and whether to create multiple SVCs to
   the same NHS.


6. Issues and Scalability

   The techniques described above would allow the creation of a strongly
   differentiated class of service within an IP network that primarily
   uses an NBMA network for interconnection between hosts and or
   routers.  The shortcuts created by NHRP will be exclusive per
   associated Class-of-Service (rather than per flow), and will be used
   in full-duplex mode.  The forwarding overhead to use a shortcut is
   "simply" using a combination of both destination address and QoS to
   hash the NHRP cache. The primary limitation could be the availability
   of some form of "sub-addressing" scheme for the NHRP clients and
   servers that allows the local association between the called and
   calling addresses and a CoS.

   This solution scales well due to a simple but consistent forwarding
   Policy definition, the limited number of SVCs, and since the number
   of NHRP cache entries is limited per CoS per destination prefix.

7. Security Considerations

   Security is not addressed in the current version of this document





















Turner, Staegemeir                                              [Page 7]


INTERNET DRAFT      Differentiated Services with NHRP         March 1998


References

   [1] Almquist, P. "Type of Service in the Internet Protocol Suite".
       RFC 1349, July 1992.

   [2] NMBA Next Hop Resolution Protocol (NHRP) , J. Luciani,
       D. Katz, D. Piscitello and B. Cole. Work in progress.


Authors' Address

   Steve Turner
   SITA Network Projects Department.
   1041, Route des Dolines
   F-06560 Valbonne / France
   Phone +33 4 92 96 63 17
   email st@pt.nce.sita.int

   Bernd Staegemeir
   SITA Research & Development
   1041, Route des Dolines
   F-06560 Valbonne / France
   Phone +33 4 92 96 65 40
   email bst@ed.nce.sita.int




























Turner, Staegemeir                                              [Page 8]