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]