Internet Draft
Internet Draft Gerald R. Ash
Young Lee
AT&T Labs
October 1999
Expires: April 2000
Routing of Multimedia Connections Across
TDM-, ATM-, and IP-Based Networks
<draft-ash-itu-sg2-qos-routing-02.txt>
STATUS OF THIS MEMO:
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
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/ietf/1id-abstracts.txt. The list of Internet-Draft
Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited.
ABSTRACT:
This draft presents the ongoing work in ITU-T SG2 Question 2/2 on
Recommendation E.351 "Routing of Multimedia Connections Across TDM-, ATM-,
and IP-based Networks." There are many network operators who have
implemented multiple networks using different network-layer (layer-3)
routing protocols, which include TDM-, ATM-, and/or IP-based technology.
Rapid growth of multimedia IP-based services has led in turn to ATM and IP
technology being implemented and/or planned for PSTNs. Established routing
methods are recommended for application across network types (summarized in
Table 1 of the Recommendation), and include the following: a) E.164/NSAP
based number translation/routing, b) automatic generation of routing tables
based on network topology and status, c) automatic update and
synchronization of topology databases, d) dynamic route selection, and e)
QoS resource management. Signaling and information-exchange requirements
needed to support these routing methods are recommended, and include the
connectivity management and routing policy parameters summarized in Table 4
of the Recommendation.
***************************************************************************
NOTE: A MICROSOFT WORD VERSION OF THIS DRAFT (WITH THE FIGURES) IS
AVAILABLE ON REQUEST
***************************************************************************
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 1]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
Table of Contents
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.0 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.0 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.0 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.0 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.0 Recommended Routing Methods . . . . . . . . . . . . . . . . . 10
6.1 Number Translation/Routing . . . . . . . . . . . . . . . . . . 12
6.2 Routing Table Management . . . . . . . . . . . . . . . . . . . 13
6.2.1 Topology Update . . . . . . . . . . . . . . . . . . . . . . 14
6.2.2 Status Update . . . . . . . . . . . . . . . . . . . . . . . 14
6.2.3 Query for Status . . . . . . . . . . . . . . . . . . . . . . 14
6.2.4 Routing Recommendation . . . . . . . . . . . . . . . . . . . 15
6.3 Route Selection . . . . . . . . . . . . . . . . . . . . . . . 15
6.4 QoS Resource Management . . . . . . . . . . . . . . . . . . . 16
6.4.1 QoS Resource Management Steps. . . . . . . . . . . . . . . . 16
6.4.2 Bandwidth-Allocation, Bandwidth-Protection, and Priority-
Routing Issues . . . . . . . . . . . . . . . . . . . . . . . 18
6.4.3 Other QoS Routing Constraints. . . . . . . . . . . . . . . . 21
6.4.4 Priority Queuing. . . . . . .. . . . . . . . . . . . . . . . 22
6.5 Harmonization of Routing Methods Standards . . . . . . . . . . 22
7.0 Signaling and Information Exchange Requirements. . . . . . . . 23
7.1 Number Translation/Routing Information-Exchange Parameters . . 26
7.2 Routing Table Management Information-Exchange Parameter. . . . 27
7.3 Route Selection Information-Exchange Parameters. . . . . . . . 28
7.4 QoS Resource Management Information-Exchange Parameters. . . . 29
7.5 Harmonization of Information-Exchange Standards. . . . . . . . 30
7.6 Open Routing Application Programming Interface . . . . . . . . 30
8.0 Examples of Internetwork Routing . . . . . . . . . . . . . . . 31
8.1 Internetwork E Uses a Mixed Route Selection Methods. . . . . . 31
8.2 Internetwork E Uses a Single Route Selection Methods . . . . . 33
9.0 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 34
ANNEX A TDM-Based Intranetwork Routing Methods . . . . . . . . . . 34
A.1 TDM-Based Number Translation/Routing . . . . . . . . . . . . . 34
A.2 TDM-Based Routing Table Management & Route Selection . . . . . 35
A.2.1 Fixed Routing (FR) . . . . . . . . . . . . . . . . . . . . . 35
A.2.2 Time-Dependent Routing (TDR) . . . . . . . . . . . . . . . . 35
A.2.3 State-Dependent Routing (SDR). . . . . . . . . . . . . . . . 36
A.2.4 Event-Dependent Routing (EDR). . . . . . . . . . . . . . . . 37
A.3 TDM-Based QoS Resource Management . . . . . . . . . . . . . . 38
ANNEX B ATM-Based Intranetwork Routing Methods . . . . . . . . . . 38
B.1 ATM-Based Number Translation/Routing . . . . . . . . . . . . . 39
B.2 ATM-Based Routing Table Management & Route Selection . . . . . 39
B.3 ATM-Based QoS Resource Management . . . . . . . . . . . . . . 41
ANNEX C IP-Based Intranetwork Routing Methods . . . . . . . . . . 44
C.1 IP-Based Number Translation/Routing .. . . . . . . . . . . . . 45
C.2 IP-Based Routing Table Management & Route Selection . . . . . 45
C.3 IP-Based QoS Resource Management . . . . . . . . . . . . . . 46
ANNEX D BIBLIOGRAPHY . . . . . . . . . . . . . . . . . . . . . . . 53
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 2]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
1.0 Introduction
There are many network operators who have implemented multiple networks
using different protocols, which include Public Switched Telephone Networks
(PSTNs) which use Time Division Multiplexing (TDM) technology, Asynchronous
Transfer Mode (ATM) technology, and/or Internet Protocol (IP) technology.
The very rapid growth of data services driven primarily by multimedia
IP-based services has led in turn to the rapid growth of ATM and IP
technology being implemented and/or planned for PSTNs. Also there is
interest in carrying traditional PSTN voice services over ATM- and IP-based
networks, leading to the convergence in many instances of voice and data
services onto a common network. Therefore it is important to address the
interworking of voice and data services over TDM-, ATM,- and IP-based PSTN
networks, and - in particular - to address the interworking of routing
methods across these different types of networks. This Recommendation
addresses routing used within single networks and across different networks;
it deals with both routing methods and the information exchange required to
support such methods. The treatment of routing methods includes
recommendations on a) number translation/routing, b) routing table
management, c) route selection, and d) quality-of-service (QoS) resource
management. The signaling and information-exchange requirements of these
routing methods are also addressed and recommendations made.
Various routing protocols are used in TDM-, ATM-, and IP-based networks. In
TDM-based networks, for example, Recommendation E.350 describes fixed and
dynamic routing methods for use in TDM-based networks. In ATM-based
networks, for example, the Private Network-to-Network Interface (PNNI)
standard adopted by the ATM Forum [ATM960055] provides for
* exchange of node and link status information,
* automatic update and synchronization of topology databases,
* fixed and/or dynamic route selection based on topology and status
information, and
* signaling and information exchange standards.
In IP-based networks, for example, the open shortest route first (OSPF),
border gateway protocol (BGP), multiprotocol label switching (MPLS), and
other standards adopted by the Internet Engineering Task Force [M98, S95,
J99] provide for all of the same features listed above for PNNI, but in a
connectionless IP-based packet network.
There is interest in interworking fixed and dynamic routing methods across
TDM-, ATM-, and IP-based networks to include fixed routing (FR),
time-dependent routing (TDR), state-dependent routing (SDR), and
event-dependent routing (EDR) methods, applied primarily in nonhierarchical
networks. A multimedia connection will often traverse more than one network
type, and hence may be routed end-to-end using more than one fixed or
dynamic routing method. This Recommendation covers the interworking of
different types of fixed and dynamic routing methods and their associated
information-exchange needs at the interface across various network types, in
order to complete a connection originating in one node and terminating in
another, where the originating, via, and destination nodes may operate
different routing methods. This Recommendation addresses the interworking
of routing methods for all services including multimedia services and only
considers point-to-point connections (multipoint connections are left for
future work).
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 3]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
Substantial improvements in network cost efficiency and robustness result
from the introduction of efficient routing. A framework is needed to
support interworking of different routing methods and information-exchange
across various TDM-, ATM-, and IP-based network types, perhaps implemented
on different vendor equipment, for routing between network operators,
national as well as international. Standardization of information flows is
needed, so that switching equipment from different vendors can interwork
across various network types to implement routing strategies in a
coordinated fashion. Routing interworking standards are needed for
application to interworking between multivendor networks of various types.
This includes the international network among many network operators who use
different vendor equipment and networking protocols, including TDM-, ATM-,
and IP-based protocols.
More specifically, this Recommendation addresses the number
translation/routing, routing table management, route selection, and
quality-of-service (QoS) resource management methods needed for routing
within each network type and for routing interworking between network types.
In particular, the following established routing methods employed within the
identified network type(s) are recommended for application across network
types:
a) the E.164/NSAP based number translation/routing methods applied in
TDM- and ATM-based networks,
b) the automatic generation of routing tables based on network topology
and status applied in TDM-, ATM-, and IP-based networks,
c) the automatic update and synchronization of topology database
methods applied in ATM- and IP-based networks,
d) the dynamic route selection methods applied in TDM-based networks,
and
e) the QoS resource management methods applied in TDM-based networks.
Table 1 of the Recommendation summarizes the recommended routing methods
across various network technologies.
In addition, this Recommendation identifies the signaling and
information-exchange requirements needed to support these routing methods.
These include
a) carrying E.164 NSAPs, international network routing addresses, and
IP addresses in connection-setup information elements (IEs),
b) the topology update information exchange applied in ATM- and
IP-based networks,
c) the routing table design information exchange applied in TDM-based
networks,
d) the route selection information exchange applied in ATM-based
networks, and
e) originating-node-controlled (source) routing, with specification of
via and destination nodes in a parameter in a connection-setup IE, and
return of control to the originating node with a
crankback/bandwidth-not-available parameter in the connection-release IE.
Table 4 of the Recommendation summarizes the recommended signaling and
information-exchange parameters to support the routing methods recommended
in Table 1, as well the recommended standards to support the parameters.
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 4]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
2.0 Scope
This Recommendation addresses routing methods and information exchange
needed within and between TDM-, ATM-, and IP-based network and routing
technology. It recommends a compatible set of routing methods based on
established practice, and also recommends compatible information exchange to
support these routing methods across the interfaces between network types.
In addition, the Recommendation addresses the cases when PSTN's evolve to
incorporate IP- or ATM-based technology. For the latter two cases, the
Recommendation addresses harmonized standards for routing and information
exchange. These harmonized standards would span ITU-T and IETF
recommendations in the case of PSTNs incorporating IP-based technology, and
span ITU-T and ATM Forum recommendations in the case of PSTNs incorporating
ATM-based technology. The Recommendation therefore addresses three topics:
a) a compatible set of routing methods,
b) compatible information exchange supporting the routing methods
within each network types and at the network-network interface between
network types, and
c) harmonized standards for routing methods and information exchange
when PSTNs incorporate IP- or ATM-based technology.
On the topic of routing methods, covered in Section 6, this Recommendation
addresses the number translation/routing, routing table management, route
selection, and QoS resource management methods needed for routing within
each network type and for interworking between network types, including
TDM-, ATM-, and IP-based networks. It recommends that compatible routing
methods be employed for these functions within and across network types;
these recommended methods are based on establishing routing practice within
these network types.
The recommended routing methods are for network-layer logical routing
(sometimes referred to as "layer-3" routing), as opposed to link layer
("layer-2") routing or physical-layer ("layer-1") routing. In particular,
the routing methods addressed include those discussed in
* Recommendations E.170 and E.350 for TDM-based routing methods,
* User-to-Network Interface (UNI), Private Network-to-Network
Interface (PNNI), ATM Inter-Network Interface (AINI), and Bandwidth
Modify for ATM-based routing methods, and
* Open Shortest Path First (OSPF), Border Gateway Protocol (BGP), and
Multiprotocol Label Switching (MPLS) for IP-based routing methods.
The scope of the recommended routing methods includes the establishment of
connections for narrowband, wideband, and broadband multimedia services
within multiservice networks and between multiservice networks. These
services include constant bit rate (CBR), variable bit rate (VBR),
unassigned bit rate (UBR), and available bit rate (ABR) traffic classes.
The Recommendation illustrates the functionality for setting up a connection
from an originating node in one network to a destination node in another
network, using one or more routing methods across networks of various types,
as illustrated in Figure 1.
The Figure illustrates a multimedia connection between two PCs which carries
traffic for a combination of voice, video, and image applications. For this
purpose a logical point-to-point connection is established from the PC
served by node a1 to the PC served by node c2. The connection could be a
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 5]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
CBR ISDN connection across TDM-based network A and ATM-based network C, or
it might be a VBR connection via IP-based network B. Gateway nodes a3, b1,
b4, and c1 provide the interworking capabilities between the TDM-, ATM-, and
IP-based networks. The actual multimedia connection might be routed, for
example, on a route consisting of nodes a1-a2-a3-b1-b4-c1-c2, or possibly on
a different route through different gateway nodes. Compatible routing
methods are recommended for interworking between the gateway nodes. In the
Recommendation we address point-to-point connections and do not address
multipoint connections, which are left for further study.
<>
On the topic of compatible information exchange, covered in Section 7, the
Recommendation addresses signaling and information exchange supported within
each network technology. It is recommended that for interworking between
network types that the information exchange at the interface be compatible
across network types. Information exchange parameters are recommended to be
supported within each network type and across the interfaces between network
types. These parameters support the recommended routing methods so that
compatible routing methods are supported by compatible information exchange
when interworking between network types. It is also recommended that these
information exchange parameters be supported within PSTNs employing IP- or
ATM-based technology. In the Recommendation we assume the separation of
call control signaling for call establishment from
connection/bandwidth-allocation control signaling for bearer channel
establishment.
The third topic of harmonized standards is covered in Section 6 for routing
methods and Section 7 for information-exchange. The harmonized standards
pertain to the case when PSTNs such as network B and network C incorporate
IP- or ATM-based technology. For example, assuming network B is a PSTN
incorporating IP-based technology, established routing methods and
compatible information-exchange are recommended to be applied. Achieving
this will affect recommendations both with ITU-T and IETF that apply to the
impacted routing and information exchange functions. Recommendations are
made in Sections 6 and 7 to standardize the routing methods and
information-exchange parameters within the affected recommendations.
Tables 1 and 4 provide an overall summary of the recommendations, where
* Table 1 identifies the recommended routing methods across various
network technologies, and
* Table 4 identifies the recommended signaling and
information-exchange parameters to support the routing methods
recommended in Table 1, as well the recommended standards to
support the parameters.
The Recommendation gives several examples of using the routing methods and
information exchange parameters when interworking between routing methods
across different network types.
3.0 Definitions
Link: a bandwidth transmission medium between nodes that
is engineered as a unit;
Destination node: terminating node within a given network;
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 6]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
Node: a network element (switch, router/switch, exchange)
providing switching and routing capabilities, or
an aggregation of such network elements representing
a network;
O-D pair: an originating node to destination node pair for a
given connection/bandwidth-allocation request;
Originating node: originating node within a given network;
Route: a concatenation of links providing a
connection/bandwidth-allocation between an O-D pair;
Route set: a set of routes connecting the same O-D pair;
Routing table: describes the route choices and selection rules to
select one route out of the route set for a
connection/bandwidth-allocation request
Traffic stream: a class of connection requests with the same
traffic characteristics;
Via node: an intermediate node in a route within a given
network;
4.0 References
[E.164] ITU-T Recommendation, The International Telecommunications
Numbering Plan.
[E.170] ITU-T Recommendation, Traffic Routing.
[E.177] ITU-T Recommendation, B-ISDN Routing.
[E.191] ITU-T Recommendation, B-ISDN Numbering and Addressing, October
1996.
[E.350] ITU-T Recommendation, Dynamic Routing Interworking.
[E.352] ITU-T Recommendation, Routing Guidelines for Efficient Routing
Methods.
[E.353] ITU-T Draft Recommendation, Routing of Calls when Using
International Network Routing Addresses
[E.412] ITU-T Recommendation, Network Management Controls.
[G.723.1] ITU-T Recommendation, Dual Rate Speech Coder for Multimedia
Communications Transmitting at 5.3 and 6.3 kbit/s, March 1996.
[H.225.0] ITU-T Recommendation, Media Stream Packetization and
Synchronization on Non-Guaranteed Quality of Service LANs, November 1996.
[H.245] ITU-T Recommendation, Control Protocol for Multimedia
Communication, March 1996.
[H.246] Draft ITU-T Recommendation, Interworking of H.Series Multimedia
Terminals with H.Series Multimedia Terminals and Voice/Voiceband Terminals
on GSTN and ISDN, September 1997.
[H.323] ITU-T Recommendation, Visual Telephone Systems and Equipment for
Local Area Networks which Provide a Non-Guaranteed Quality of Service,
November 1996.
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 7]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
[I.211] ITU-T Recommendation, B-ISDN Service Aspects, March 1993.
[I.324] ITU-T Recommendation, ISDN Network Architecture, 1991.
[I.327] ITU-T Recommendation, B-ISDN Functional Architecture, March 1993.
[I.356] ITU-T Recommendation, B-ISDN ATM Layer Cell Transfer Performance,
October 1996.
[Q.71] ITU-T Recommendation, ISDN Circuit Mode Switched Bearer Services.
[Q.2761] ITU-T Recommendation, Broadband Integrated Services Digital
Network (B-ISDN) Functional Description of the B-ISDN User Part (B-ISUP) of
Signaling System Number 7.
[Q.2931] ITU-T Recommendation, Broadband Integrated Services Digital
Network (B-ISDN) - Digital Subscriber Signalling System No. 2 (DSS 2) -
User-Network Interface (UNI) Layer 3 Specification for Basic Call/Connection
Control, February 1995.
5.0 Abbreviations
AAR Automatic Alternate Routing
ABR Available Bit Rate
ADR Address
AESA ATM End System Address
AFI Authority and Format Identifier
AINI ATM Inter-Network Interface
ARR Automatic Rerouting
AS Autonomous System
ATM Asynchronous Transfer Mode
B Busy
BGP Border Gateway Protocol
BICC Bearer Independent Call Control
B-ISDN Broadband Integrated Services Digital Network
BNA Bandwidth Not Available
BW Bandwidth
BWIP Bandwidth in Progress
BWOF Bandwidth Offered
BWOV Bandwidth Overflow
BWPC Bandwidth Peg Count
CAC Call Admission Control
CBK Crankback
CBR Constant Bit Rate
CCS Common Channel Signaling
CIC Call Identification Code
CRLDP Constraint-Based Routing Label Distribution Protocol
CRLSP Constraint-Based Routing Label Switched Path
DADR Distributed Adaptive Dynamic Routing
DAR Dynamic Alternate Routing
DCC Data Country Code
DCR Dynamically Controlled Routing
DIFFSERV Differentiated Services
DN Destination Node
DNHR Dynamic Nonhierarchical Routing
DoS Depth-of-Search
DSP Domain Specific Part
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 8]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
DTL Designated Transit List
EDR Event Dependent Routing
ER Explicit Route
FR Fixed Routing
GCAC Generic Call Admission Control
GOS Grade of Service
HL Heavily Loaded
IAM Initial Address Message
ICD International Code Designator
IDI Initial Domain Identifier
IDP Initial Domain Part
IE Information Element
IETF Internet Engineering Task Force
II Information Interchange
ILBW Idle Link Bandwidth
INRA International Network Routing Address
IP Internet Protocol
IPDC Internet Protocol Device Control
LBL Link Blocking Level
LC Link capability
LDP Label Distribution Protocol
LL Lightly Loaded
LLR Least Loaded Routing
LSA Link State Advertisement
LSP Label Switched Path
MEGACO Media Gateway Control
MOD Modify
MPLS Multiprotocol Label Switching
NANP North American Numbering Plan
N-ISDN Narrowband Integrated Services Digital Network
NSAP Network Service Access Point
ODR Optimized Dynamic Routing
ON Originating Node
OSPF Open Shortest Route First
PAR Parameters
PNNI Private Network-to-Network Interface
PSTN Public Switched Telephone Network
PTSE PNNI Topology State Elements
QoS Quality of Service
R Reserved
RP Routing Processor
RQE Routing Query Element
RSE Routing State Element
RRE Routing Recommendation Element
RSVP Resource Reservation Protocol
RTNR Real-Time Network Routing
SCP Service Control Point
SDR State-Dependent Routing
SI Service Identity
SIP Session Initiation Protocol
SS7 Signaling System 7
STR State- and Time-Dependent Routing
SVC Switched Virtual Circuit
SVP Switched Virtual Path
TBW Total Bandwidth
TBWIP Total Bandwidth In Progress
TDR Time-Dependent Routing
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 9]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
TIPHON Telecommunications and Internet Protocol
Harmonization Over Networks
TLV Type/Length/Value
ToS Type of Service
TSE Topology State Element
TR Trunk Reservation
TRAF Traffic
TSE Topology State Element
UBR Unassigned Bit Rate
UNI User-Network Interface
VBR Variable Bit Rate
VC Virtual Circuit
VCI Virtual Circuit Identifier
VN Via Node
VNET Virtual Network
VPI Virtual Path Identifier
WIN Worldwide Intelligent Network (Routing)
6.0 Recommended Routing Methods
ANNEXES A, B, and C describe established intranetwork routing methods used
within TDM-, ATM-, and IP-based networks; the methods described are
recommended for application across these network types. In the ANNEXES we
also discuss the signaling and information-exchange requirements of these
routing methods. TDM-based networks, ATM-based networks, and IP-based
networks, as discussed in ANNEX A, ANNEX B, and ANNEX C, respectively.
Table 1 summarizes the routing methods supported within each network
technology which are recommended to be supported across network types. Five
network technologies are identified which are supported by routing standards
from the specified organization. In the cases of PSTN/ATM-based and
PSTN/IP-based network technologies, harmonized standards are recommended,
which is discussed further in Section 6.5. Routing methods are categorized
in Table 1 by considerations of a) number translation/routing, b) routing
table management, c) route selection, and d) QoS resource management.
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 10]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
Table 1
Recommended Routing Methods for Various Network Technologies
--------------------------------------------------------------------
Routing Method Network Technology
(Routing Standards Source)
--------------------------------------------------------------------
TDM- ATM- IP- PSTN/ PSTN/
Based Based Based ATM- IP-
Based Based
(ITU-T (ATMF (IETF (Harmon (Harmon
Stds.) Stds.) Stds.) ized ized
Stds.) Stds.)
--------------------------------------------------------------------
Number E.164, UNI, Sect. Sect. Sect.
Translation/ E.191, PNNI, 6.1 6.1 6.1
Routing E.353 AINI
BW-
MODIFY
--------------------------------------------------------------------
Routing Topology Update Sect. UNI, OSPF, Sect. Sect.
Table 6.2.1 PNNI, BGP, 6.2.1 6.2.1
AINI, MPLS
BW-
MODIFY
Management Status Update E.350 UNI, OSPF, Sect. Sect.
PNNI, BGP, 6.2.2 6.2.2
AINI, MPLS
BW-
MODIFY
Query for E.350 Sect. Sect. Sect. Sect.
Status 6.2.3 6.2.3 6.2.3 6.2.3
Routing Recom. E.350 Sect. Sect. Sect. Sect.
6.2.4 6.2.4 6.2.4 6.2.4
--------------------------------------------------------------------
Route Fixed Routing E.170, UNI, OSPF, Sect. Sect.
Selection E.177 PNNI, BGP, 6.3 6.3
E.350 AINI, MPLS
BW-
MODIFY
Selection Time Dep. Rtg. E.350 Sect. Sect. Sect. Sect.
6.3 6.3 6.3 6.3
State Dep. Rtg. E.350 UNI, OSPF, Sect. Sect.
PNNI, BGP, 6.3 6.3
AINI, MPLS
BW-
MODIFY
Event Dep. Rtg. E.350 Sect. Sect. Sect. Sect.
6.3 6.3 6.3 6.3
--------------------------------------------------------------------
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 11]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
--------------------------------------------------------------------
QoS Resource BW Allocation Sect. UNI, OSPF, Sect. Sect.
Management & Protection 6.4 PNNI, BGP, 6.4 6.4
AINI, MPLS
BW-
MODIFY
Priority Rtg. Sect. UNI, OSPF, Sect. Sect.
6.4 PNNI, BGP, 6.4 6.4
AINI, MPLS
BW-
MODIFY
Priority N/A DIFF- DIFF- Sect. Sect.
Queuing SERV SERV 6.4 6.4
OSPF,
BGP,
MPLS
--------------------------------------------------------------------
These routing methods are recommended for use within each network type and
for interworking across network types. Therefore it is recommended that all
routing methods identified in Table 1 be supported by standards for the five
network technologies identified. That is, it is recommended that standards
be developed for all routing methods not currently supported, which are
identified in Table 1 as References to Sections of this Recommendation.
This will ensure routing method compatibility when interworking between the
TDM-, ATM-, and IP-based network types, as denoted in the left three network
technology columns.
We first discuss the routing methods identified by the rows of Table 1, and
we then discuss the harmonization of PSTN/ATM-Based and PSTN/IP-Based
routing methods, as identified by columns 4 and 5 of Table 1. In Sections
6.1 to 6.4 we describe the routing methods recommended in Table 1,
respectively, for number translation/routing, routing table management,
route selection, and QoS resource management. ANNEXES A-C describe the
routing methods supported within each network type by either current
standards or standards currently in progress. These are the basis for the
recommended routing methods which are summarized in the Sections 6.1 to 6.4.
Please refer to the appropriate Section in the ANNEX(s) for more details and
examples. In Section 6.5, we discuss the harmonization of routing methods
standards for the two technology cases in the right two columns of Table 1,
in which PSTNs incorporate ATM- or IP-based technology.
To support this routing interworking across network types, it is further
recommended that the information exchange at the interface be compatible
across network types, as discussed in Section 7. Standardizing the
recommended routing methods and information exchange also supports the
network technology cases in the right two columns of Table 1, in which PSTNs
incorporate ATM- or IP-based technology
6.1 Number Translation/Routing
The E.164/NSAP based numbering and addressing methods discussed in ANNEX A.1
and B.1, as applied in TDM- and ATM-based networks, are recommended for
routing within and between network types. Recommendation E.164 identifies
the numbering plan currently used for TDM-based networks, and Recommendation
E.191 specifies the B-ISDN address structure, as discussed in ANNEX A.1. A
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 12]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
further recommendation pertaining to number translation/routing methods is
the use of international routing addresses (INRAs) in the connection
/bandwidth-allocation setup in order to route a connection to a particular
destination node [E.353].
These number translation/routing methods are recommended to be extended to
IP-based networks, and as discussed in ANNEX C.1, proposals have been made
[ETSIa, ETSIb, ETSIc, PL99] to interwork between IP addressing and E.164
numbering/addressing. In particular, a translation database based on
domain name service (DNS) technology is proposed to convert E.164 addresses
(or names) to IP addresses. With such a capability, IP nodes can make this
translation of E.164 numbers (or names) directly to E.164-NSAP addresses,
INRAs, and IP addresses, and thereby provide interworking with TDM- and
ATM-based networks which use E.164 numbering and addressing.
Number (or name) translation, then, should result in the E.164-NSAP
addresses, INRAs, and/or IP addresses. As discussed in Section 7.1, it is
recommended that provision be made for carrying E.164-NSAP addresses, INRAs,
and IP addresses in the connection-setup IE. In Section 7.1, it is
recommended that E.164-NSAP-address, INRA, and IP-address elements be
developed within IP-based and PSTN/IP-based networks. As shown in Table 1,
it is recommended that these number translation/routing methods be developed
for IP-based and PSTN/IP-based networks. When this is the case, then
E.164-NSAP addresses, INRAs, and IP addresses will become the standard
addressing method for interworking across TDM-, ATM-, and IP-based networks.
6.2 Routing Table Management
A specific traffic routing method is characterized by the routing table used
in the method. The routing table consists of a route set and rules to
select one route from the route set for a given connection or
bandwidth-allocation request. When a connection/bandwidth-allocation
request is initiated by an originating node (ON), the ON implementing the
routing method executes the route selection rules associated with the
routing table for the connection/bandwidth-allocation to find an admissible
route from among the routes in the route set that satisfies the
connection/bandwidth-allocation request. In a particular routing method,
the set of routes assignable to the connection/bandwidth-allocation request
may be determined according to the rules associated with the routing table.
In a network with originating connection/bandwidth-allocation control, the
ON maintains control of the connection/bandwidth-allocation request. If
crankback/bandwidth-not-available is used, for example, at a via node (VN),
the preceding node maintains control of the connection/bandwidth-allocation
request even if the request is blocked on all the links outgoing from the
VN.
Routing table management information, such as topology update, status
information, or routing recommendations, is used for purposes of applying
the routing table design rules for determining route choices in the routing
table. This information is exchanged between one node and another node,
such as between the ON and DN, for example, or between a node and a network
element such as a routing processor (RP). This information is used to
generate the routing table, and then the routing table is used to determine
the route choices used in the selection of a route.
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 13]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
6.2.1 Topology Update
The automatic generation of routing tables based on network topology (and
other information such as status), which has been applied in ATM-, and
IP-based networks, is recommended for routing within and between network
types. This automatic generation function is enabled by the automatic
exchange of link, node, and reachable address information among the network
nodes. In order to achieve automatic update and synchronization of the
topology database, which is essential for routing table management, ATM- and
IP-based based networks already interpret HELLO protocol mechanisms to
identify links in the network. For topology database synchronization the
PNNI topology-state-element (PTSE) exchange is used in ATM-based networks
and link state advertisement (LSA) is used in IP-based networks to
automatically provision nodes, links, and reachable addresses in the
topology database. Use of a single peer group/autonomous system with
nonhierarchical routing is also recommended for topology update, for more
efficient routing and easier administration, and as discussed in ANNEX B.2
and C.2, is best achieved by minimizing the use of topology state (PTSE and
LSA) flooding for dynamic topology state information.
In Section 7.2, it is recommended that a topology state element (TSE) be
developed within TDM-based PSTN networks. As shown in Table 1, it is
recommended that these topology update routing methods be developed for
PSTN/TDM-based networks. When this is the case, then the HELLO and
TSE/PTSE/LSA parameters will become the standard topology update method for
interworking across TDM-, ATM-, and IP-based networks.
6.2.2 Status Update
Status update methods are recommended for use in routing table management
within and between network types. In TDM-based networks, status updates of
link and/or node status are provided by Recommendation [E.350], as described
in ANNEX A.2. Within ATM- and IP-based networks, status updates are
provided by a flooding mechanism, as described in ANNEX B.2 and C.2.
In Section 7.2, it is recommended that a routing status element (RSE) be
developed within TDM-based networks, which will be compatible with the PNNI
topology state element (PTSE) in ATM-based networks and the link state
advertisement (LSA) element in IP-based networks. As shown in Table 1, it
is recommended [E.350] that these status update routing methods be developed
for TDM-based networks. When this is the case, then the RSE/PTSE/LSA
parameters will become the standard status update method for interworking
across TDM-, ATM-, and IP-based networks.
6.2.3 Query for Status
Query for status methods are recommended for use in routing table management
within and between network types. Such methods allow efficient
determination of status information, as compared to flooding mechanisms.
Recommendation [E.350] provides for the query for status methods in
TDM-based networks, as described in ANNEX A.2.
In Section 7.2, it is recommended that a routing query element (RQE) be
developed within ATM-based, IP-based, PSTN/ATM-based, and PSTN/IP-based
networks. As shown in Table 1, it is recommended that these
query-for-status routing methods be developed for ATM-based, IP-based,
PSTN/ATM-based, and PSTN/IP-based networks. When this is the case, then the
RQE parameters will become the standard query for status method for
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 14]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
interworking across TDM-, ATM-, and IP-based networks.
6.2.4 Routing Recommendation
Routing recommendation methods are recommended for use in routing table
management within and between network types. For example, such methods
provide for a database, such as an RP, to advertise recommended routes to
network nodes based on status information available in the database.
Recommendation [E.350] provides for the routing recommendation methods in
TDM-based networks, as described in ANNEX A.2.
In Section 7.2, it is recommended that a routing recommendation element
(RRE) be developed within ATM-based, IP-based, PSTN/ATM-based, and
PSTN/IP-based networks. As shown in Table 1, it is recommended that these
routing-recommendation routing methods be developed for ATM-based, IP-based,
PSTN/ATM-based, and PSTN/IP-based networks. When this is the case, then the
RRE parameters will become the standard query for status method for
interworking across TDM-, ATM-, and IP-based networks.
6.3 Route Selection
It is recommended that route selection rules used within routing tables
should allow the use of fixed routing (FR), time-dependent routing (TDR),
state-dependent routing (SDR), and event-dependent routing (EDR) route
selection, as discussed in ANNEX A.2, and the use of multilink shortest
routes in a sparse network topology. ON controlled, or source, routing is
recommended to avoid looping and to allow interworking of different route
selection methods.
Routing tables consist of routes, and routes may be set up for individual
connection requests such as on a switched virtual circuits (SVC). Routes
may also be set up for bandwidth-allocation requests associated with
"bandwidth pipes" or "virtual trunking", such as on switched virtual paths
(SVPs) in ATM-based networks or constraint-based routing label switched
paths (CRLSPs) in IP-based networks. Routes are determined by (normally
proprietary) algorithms based on the network topology and reachable address
information. These routes can cross multiple peer groups in ATM-based
networks, and multiple autonomous systems in IP-based networks, as discussed
in ANNEX B.2 and C.2. An ON may select a route from the routing table based
on the routing rules and the QoS resource management criteria, described
next in Section 6.4, which must be satisfied on each link in the route. If
a link is not allowed based on the QoS criteria, then a release with
crankback/bandwidth-not-available parameter is used to signal that condition
to the ON in order to return the connection/bandwidth-allocation request to
the ON, which may then select an alternate route. In addition to controlling
bandwidth allocation, the QoS resource management procedures can check
end-to-end transfer delay, delay variation, and transmission quality
considerations such as loss, echo, and noise (this is further discussed in
Section 6.4.3).
Setup of a connection/bandwidth-allocation request is achieved by having the
ON identify the entire selected route including all VNs and DN in the route
in a designated-transit-list (DTL) or explicit-route (ER) parameter in the
connection-setup IE, as discussed in Section 7.3. If the QoS or traffic
parameters cannot be realized at any of the VNs in the connection setup
request, then the VN generates a crankback (CBK)/bandwidth-not-available
(BNA) parameter in the connection-release IE which allows a VN to return
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 15]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
control of the connection request to the ON for further alternate routing.
In Section 7.3, it is recommended that the DTL/ER and CBK/BNA elements be
developed within TDM-based networks, which will be compatible with the DTL
element in ATM-based networks and the ER element in IP-based networks. As
shown in Table 1, it is recommended [E.350] that these route-selection
methods be developed for TDM-based networks. Furthermore it is recommended
that TDR and EDR route-selection methods be developed for ATM-based,
IP-based, PSTN/ATM-based, and PSTN/IP-based networks. When this is the
case, then the DTL/ER and CBK/BNA parameters will become the standard
route-selection method for interworking across TDM-, ATM-, and IP-based
networks.
6.4 QoS Resource Management
QoS resource management methods are recommended for use within and between
network types. In this Section we recommend methods applicable to both
TDM-based N-ISDN networks as well as ATM-based B-ISDN networks. QoS
resource management methods, which have been applied in TDM-based networks
[A98], are being extended to ATM- and IP-based networks as discussed in
ANNEX B.3 and C.3. QoS resource management encompasses service integration,
bandwidth allocation, bandwidth protection, service priority
differentiation, and routing/queuing priority management. QoS resource
management can be applied on a per-connection basis, as described in this
Section, or can be beneficially applied to "bandwidth pipes" ("virtual
trunking") in the form of SVPs in ATM-based networks, as described in ANNEX
B.3, or CRLSPs in IP-based networks, as described in ANNEX C.3.
QoS resource management provides integration of services on a shared
network, for many classes-of-service such as:
a) CBR services including voice, 64-, 384-, and 1,536-kbps N-ISDN
switched digital data, international switched transit, priority defense
communication, virtual private network, 800/free-phone, fiber preferred, and
other services.
b) Real-time VBR services including IP-telephony, compressed video, and
other services .
c) Non-real-time VBR services including WWW file transfer, credit card
check, and other services.
d) UBR services including voice mail, email, file transfer, and other
services.
We now illustrate the recommended principles of QoS resource management,
which include both N-ISDN and B-ISDN traffic classes.
6.4.1 QoS Resource Management Steps
QoS resource management entails determining QoS resource management
parameters, that is
* service identity (SI),
* virtual network (VNET),
* link capability (LC), and
* QoS and traffic threshold parameters.
In addition to controlling bandwidth allocation, the QoS resource management
procedures can check end-to-end transfer delay, delay variation, and
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 16]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
transmission quality considerations such as loss, echo, and noise (this is
further discussed in Section 6.4.3).
The recommended QoS resource management method consists of the following
steps:
1. At the ON, the DN and QoS resource management information are determined
through the digit translation database and other service information
available at the ON.
2. The DN and QoS resource management information are used to access the
appropriate VNET and routing table between the ON and DN.
3. The connection request is set up over the first available route in the
routing table with the required transmission resource selected based on the
QoS resource management data.
In the first step, the ON translates the dialed digits to determine the
address of the DN. If multiple ingress/egress routing is used, multiple
destination node addresses are derived for the connection request. Other
data derived from connection request information includes link
characteristics, Q.931 message information elements, information interchange
(II) digits, and service control point (SCP) routing information, and are
used to derive the QoS resource management parameters (SI, VNET, LC, and
QoS/traffic thresholds). SI describes the actual service associated with
the connection request, VNET describes the bandwidth allocation and routing
table parameters to be used by the connection request, and the LC describes
the link characteristics including fiber, radio, satellite, and voice
compression, that the connection request should require, prefer, or avoid.
Each connection request is classified by its SI. A connection request for
an individual service is allocated an equivalent bandwidth equal to EQBW and
routed on a particular VNET. For CBR services the equivalent bandwidth EQBW
is equal to the average or sustained bit rate. For VBR services the
equivalent bandwidth EQBW is a function of the sustained bit rate, peak bit
rate, and perhaps other parameters. For example, EQBW equals 64 kbps of
bandwidth for CBR voice connections, 64 kbps of bandwidth for CBR ISDN
switched digital 64-kbps connections, and 384-kbps of bandwidth for CBR ISDN
switched digital 384-kbps connections.
In the second step, the SI value is used to derive the VNET. In the
multi-service, QoS resource management network, bandwidth is allocated to
individual VNETs which is protected as needed but otherwise shared. Under
normal non-blocking network conditions, all services fully share all
available bandwidth. When blocking occurs for VNET i, bandwidth reservation
acts to prohibit alternate-routed traffic and traffic from other VNETs from
seizing the allocated capacity for VNET i. Associated with each VNET are
average bandwidth (BWavg) and maximum bandwidth (BWmax) parameters to govern
bandwidth allocation and protection, which are discussed further in the next
Section. LC selection allows connection requests to be routed on specific
transmission links that have the particular characteristics required by a
connection requests. A connection request can require, prefer, or avoid a
set of transmission characteristics such as fiber transmission, radio
transmission, satellite transmission, or compressed voice transmission. LC
requirements for the connection request can be determined from the SI or by
other information derived from the signaling message or dialed number. The
routing table logic allows the connection request to skip those transmission
routes that have links that have undesired characteristics and to seek a
best match for the requirements of the connection request.
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 17]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
In the third step, the VNET routing table determines which network capacity
is allowed to be selected for each connection request. In using the VNET
routing table to select network capacity, the ON selects a first choice
route based on the routing table selection rules. Whether or not bandwidth
can allocated to the connection request on the first choice route is
determined by the QoS resource management rules given below. If a first
choice route cannot be accessed, the ON may then try alternate routes
determined by FR, TDR, SDR, or EDR route selection rules outlined in Section
A.3. Whether or not bandwidth can be allocated to the connection request on
the alternate route again is determined by the QoS resource management rules
now described.
6.4.2 Bandwidth-Allocation, Bandwidth-Protection, and Priority-Routing
Issues
This Section specifies the resource allocation controls and priority
mechanisms, and the information needed to support them. In the recommended
QoS resource management method, the connection/bandwidth-allocation
admission control for each link in the route is performed based on the
status of the link. The ON may select any route for which the first link is
allowed according to QoS resource management criteria. If a subsequent link
is not allowed, then a release with crankback/bandwidth-not-available is
used to return to the ON and select an alternate route. When used with
PNNI, the release with crankback/bandwidth-not-available is an alternative
to flooding of frequently changing link state parameters such as
available-cell-rate, and the reduction in the frequency of such parameter
flooding allows for larger peer group sizes.
Crankback/bandwidth-not-available is then an alternative to the use of a
generic call admission control (GCAC) algorithm at the ON to predict which
subsequent links in the route will be allowed.
A "least-loaded routing" strategy based on available-bit-rate on each link
in a route, such as used in several state dependent routing (SDR) dynamic
routing methods described in ANNEX A, is a well-known, successful way to
implement dynamic routing. Such state-dependent dynamic routing methods
have been used in several large-scale,TDM-based voice networks for the past
10 years [A98], in which efficient methods are used to disseminate the
available-link-bandwidth status information. However, there is a high
overhead cost to obtain the available-link-bandwidth information when using
flooding techniques, such as those used in PNNI or OSPF, for example. As a
possible way around this, good dynamic routing methods are recommended
which do not require the dynamic flooding of available-bit-rate information,
such as event dependent routing (EDR) methods, also described in ANNEX A,
and in [E.352].
Determination of the link load states is recommended for QoS resource
management to select network capacity on either the first choice route or
alternate routes. Four link load states are distinguished: lightly loaded
(LL), heavily loaded (HL), reserved (R), and busy (B). Selection of route
capacity uses the link state model and route selection depth-of-search (DoS)
model to determine if a connection request can be admitted on a given route.
The allowed DoS load state threshold determines if a connection request can
be admitted on a given link to an available bandwidth "depth." In setting
up the connection request, the ON encodes the DoS load state threshold
allowed on each link in the connection-setup IE. If a link is encountered
at a VN in which the idle link bandwidth and link load state are below the
allowed DoS load state threshold, then the VN sends a
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 18]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
crankback/bandwidth-not-available IE to the ON, which can then route the
connection request to an alternate route choice. For example, in Figure 2,
route A-B-E may be the first route tried where link A-B is in the LL state
and link B-E is in the R state.
<>
If the DoS load state allowed is HL or better, then the connection request
is routed on link A-B but will not be admitted on link B-E, wherein the
connection request will be cranked back to the originating node A to try
alternate route A-C-D-E. Here the connection request succeeds since all
links have a state of HL or better.
The recommended DoS load state threshold is a function of
bandwidth-in-progress, service priority, and bandwidth allocation
thresholds, as follows:
Table 2
Determination of Depth-of-Search (DoS) Load State Threshold
------------------------------------------------------------------------------
Load State Key Service Normal Service Best Effort
Allowed ---------------------------------- Service
First Choice Path Alternate Path
------------------------------------------------------------------------------
R if BWIPi <= if BWIPi <= BWavgi Not Allowed Not Allowed
2 * BWmaxi
HL if BWIPi <= if BWIPi <= BWmaxi if BWIPi <= Not Allowed
2 * BWmaxi BWavgi
LL All BWIPi All BWIPi All BWIPi All BWIPi
where
BWIPi = bandwidth-in-progress on VNET i
BWavgi = minimum guaranteed bandwidth required for
VNET i to carry the average
offered bandwidth load
BWmaxi = the bandwidth required for VNET i to meet the
blocking probability grade-of-service
objective = 1.1 x BWavgi
Note that all parameters are specified per ON-DN pair, and that the QoS
resource management method provides for key service and best effort service.
Key services are given higher priority routing treatment by allowing greater
route selection DoS than normal services. Best effort services are given
lower priority routing treatment by allowing lesser route selection DoS than
normal. The quantities BWavgi are computed periodically, such as every week
w, and can be exponentially averaged over a several week period, as follows:
BWavgi(w) = .5 x BWavgi(w-1) + .5 x [ BWIPavgi(w) +
BWOVavgi(w) ]
BWIPavgi = average bandwidth-in-progress across a load
set period on VNET i
BWOVavgi = average bandwidth overflow across a load set
period
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 19]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
where BWIPi and BWOVi are averaged across various load set periods, such as
morning, afternoon, and evening averages for weekday, Saturday, and Sunday,
to obtain BWIPavgi and BWOVavgi.
Illustrative values of the thresholds to determine link load states are as
follows:
Table 3
Determination of Link Load State
-----------------------------------------------
Name of State Condition
-----------------------------------------------
Busy (B) ILBWk < EQBW
Reserved (R) ILBWk * Rthrk
Heavily Loaded (HL) Rthrk < ILBWk * HLthrk
Lightly Loaded (LL) HLthrk < ILBWk
where
ILBWk = idle link bandwidth on link k
EQBW = equivalent bandwidth for connection
Rthrk = reservation bandwidth threshold for link k
= N x .05 x TBWk for bandwidth reservation
level N
HLthrk = heavily loaded bandwidth threshold for
link k
= Rthrk + .05 x TBWk
TBWk = the total bandwidth required on link k to
meet the blocking probability
grade-of-service objective for connection
requests on their first route choice.
The recommended QoS resource management method implements bandwidth
reservation logic to favor connections routed on the first choice route in
situations of link congestion. If link blocking is detected, bandwidth
reservation is immediately triggered and the reservation level N is set for
the link according to the level of link congestion. In this manner traffic
attempting to alternate-route over a congested link is subject to bandwidth
reservation, and the first choice route traffic is favored for that link.
At the same time, the LL and HL link state thresholds are raised accordingly
in order to accommodate the reserved bandwidth capacity for the VNET.
Figure 3 illustrates bandwidth allocation and the mechanisms by which
bandwidth is protected through bandwidth reservation.
<>
Under normal load bandwidth is fully shared but under overload bandwidth is
protected through the reservation mechanisms wherein each virtual network
can use its allocated bandwidth. Under failure, however, the reservation
mechanisms operate to give the key services their allocated bandwidth before
lower priority services are allocated theirs. Best effort services normally
do not reserve bandwidth, and steps are taken to ensure that reserved
bandwidth is used efficiently. Illustrations are given in [A98] of the
robustness of dynamic bandwidth reservation in protecting the preferred
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 20]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
traffic across wide variations in traffic conditions.
The reservation level N (for example, N may have 1 of 4 levels), is
calculated for each link k based on the link blocking level and the
estimated link traffic. The link blocking level is equal to the equivalent
bandwidth overflow count divided by the equivalent bandwidth peg count over
the last periodic update interval, which is typically three minutes. That
is
BWOVk = equivalent bandwidth overflow count on link
k
BWPCk = equivalent bandwidth peg count on link k
LBLk = link blocking level on link k
= BWOVk/BWPCk
If LBLk exceeds a threshold value, the reservation level N is calculated
accordingly. The reserved bandwidth and link states are calculated based on
the total link bandwidth required on link k, TBWk, which is computed
on-line, for example every 1-minute interval m, and approximated as follows:
TBWk(m) = .5 x TBWk(m-1) + .5 x [ 1.1 x TBWIPk(m) +
TBWOVk(m) ]
TBWIPk = sum of the bandwidth in progress (BWIPi) for
all VNETs i
for connections on their first choice route
over link k
TBWOVk = sum of bandwidth overflow (BWOVi) for all
VNETs i for connections on their first
choice route over link k
Therefore the reservation level and load state boundary thresholds are
proportional to the estimated required bandwidth traffic load, which means
that the bandwidth reserved and the bandwidth required to constitute a
lightly loaded link rise and fall with the traffic load, as, intuitively,
they should.
6.4.3 Other QoS Routing Constraints
Other QoS routing constraints are taken into account in the recommended QoS
resource management and route selection methods in addition to bandwidth
allocation, bandwidth protection, and priority routing. These include
end-to-end transfer delay, delay variation [G99a], and transmission quality
considerations such as loss, echo, and noise [D99, G99a, G99b].
Additionally, link capability (LC) selection allows connection requests to
be routed on specific transmission media that have the particular
characteristics required by these connection requests. In general, a
connection request can require, prefer, or avoid a set of transmission
characteristics such as fiber optic or radio transmission, satellite or
terrestrial transmission, or compressed or uncompressed transmission. The
routing table logic allows the connection request to skip links that have
undesired characteristics and to seek a best match for the requirements of
the connection request. For any SI, a set of LC selection preferences is
specified for the connection request. LC selection preferences can override
the normal order of selection of routes. If a LC characteristic is
required, then any route with a link that does not have that characteristic
is skipped. If a characteristic is preferred, routes having all links with
that characteristic are used first. Routes having links without the
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 21]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
preferred characteristic will be used next. A LC preference is set for the
presence or absence of a characteristic. For example, if fiberoptic
transmission is required, then only routes with links having Fiberoptic=Yes
are used. If we prefer the presence of fiberoptic transmission, then routes
having all links with Fiberoptic=Yes are used first, then routes having some
links with Fiberoptic=No.
6.4.4 Priority Queuing
In addition to the recommended QoS bandwidth management procedure at the
time of connection request set-up, a QoS priority of service queuing
capability is recommended during the time the connection is established. At
each link, a queuing discipline is recommended such that the packets or
cells being served are given priority in the following order: CBR key
service, VBR real-time key service, VBR non-real-time key service, CBR
normal service, VBR real-time normal service, VBR non-real-time normal
service, and UBR best effort service.
6.4.5 Recommended Standards Developments for QoS Resource Management Methods
In Section 7.4, it is recommended that the quality-of-service-parameter
(QoS-PAR) and traffic-parameter (TRAF-PAR) elements be developed within
TDM-based networks to support bandwidth allocation and protection, which
will be compatible with the QoS-PAR and TRAF-PAR elements in ATM-based and
IP-based networks. In addition, it is recommended in Section 7.4 that the
depth-of-search (DoS) parameter element be developed within TDM-based
networks, which will be compatible with the DoS element in ATM-based and
IP-based networks. Finally, it is recommended in Section 7.4 that the
differentiated services (DIFFSERV) elements should be developed in ATM-based
and IP-based networks to support priority queuing. As shown in Table 1, it
is recommended [E.350] that these QoS-resource-management methods be
developed for TDM-based networks. When this is the case, then the QoS-PAR,
TRAF-PAR, DoS, and DIFFSERV parameters will become the standard
QoS-resource-management methods for interworking across TDM-, ATM-, and
IP-based networks.
6.5 Harmonization of Routing Methods Standards
Harmonization of routing methods standards are recommended for the two
technology cases in the right two columns of Table 1, in which PSTNs
incorporate ATM- or IP-based technology. For example, the harmonized
standards pertain to the case when PSTNs such as network B and network C in
Figure 1 incorporate IP- or ATM-based technology. Assuming network B is a
PSTN incorporating IP-based technology, established routing methods and
compatible information-exchange are recommended to be applied. Achieving
this will affect recommendations both with ITU-T and IETF that apply to the
impacted routing and information exchange functions.
Contributions to the ATM Forum and IETF are necessary to address
a) needed number translation/routing functionality, which includes
support for international network routing address and IP address parameters,
b) needed routing table management functionality, which includes
query-for-status and routing-recommendation methods,
c) needed route selection functionality, which includes time dependent
routing and event dependent routing.
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 22]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
7.0 Signaling and Information Exchange Requirements
Table 4 summarizes the recommended signaling and information exchange
methods supported within each routing technology which are recommended to be
supported across network types. Table 4 identifies
a) the recommended information-exchange parameters, shown in non-bold
type, to support the routing methods recommended in Section 6 (Table 1), and
b) the recommended standards, shown in bold type, to support the
information-exchange parameters.
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 23]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
Table 4
Recommended Signaling and Information-Exchange Parameters
to Support Routing Methods
(Recommended Standards in Parenthesis)
--------------------------------------------------------------------
Routing Method Network Technology
(Routing Standards Source)
--------------------------------------------------------------------
TDM- ATM- IP- PSTN/ PSTN/
Based Based Based ATM- IP-
Based Based
(ITU-T (ATMF (IETF (Harmon (Harmon
Stds.) Stds.) Stds.) ized ized
Stds.) Stds.)
--------------------------------------------------------------------
Number E.164- E.164- E.164- E.164- E.164
Translation ADR, NSAP, NSAP, NSAP, NSAP,
Routing INRA CIC INRA, INRA, INRA,
(E.164, (UNI, IP-ADR, IP-ADR, IP-ADR,
E.191, PNNI, CIC CIC CIC
E.353, AINI, (Sect. (Sect. (Sect.
SS7 BW- 7.1) 7.1) 7.1)
MODIFY)
--------------------------------------------------------------------
Routing Topology Update HELLO HELLO, HELLO, HELLO, HELLO
Table TSE PTSE LSA TSE TSE
Management (Sect. (UNI, (OSPF, (Sect. (Sect.
7.2) PNNI, BGP, 7.2) 7.2)
AINI, MPLS)
BW-
MODIFY)
Status Update RSE PTSE LSA RSE RSE
(E.350, (UNI, (OSPF,
SS7) PNNI, BGP,
AINI, MPLS)
BW-
MODIFY)
Query for RQE RQE RQE RQE RQE
Status (E.350, (Sect. (Sect. (Sect. (Sect.
SS7) 7.2) 7.2) 7.2) 7.2)
Routing Recom. RRE RRE RRE RRE RRE
(E.350, (Sect. (Sect. (Sect. (Sect.
SS7) 7.2) 7.2) 7.2) 7.2)
--------------------------------------------------------------------
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 24]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
--------------------------------------------------------------------
Route Fixed Routing DTL/ER, DTL, ER, BNA DTL/ER, DTL/ER,
Selection CBK/BNA CBK (OSPF, CBK/BNA CBK/BNA
(E.170, (UNI, BGP, (Sect. (Sect.
E.350, PNNI, MPLS) 7.3) 7.3)
SS7) AINI,
BW-
MODIFY)
Time Dep. Rtg. DTL/ER, DTL/ER, DTL/ER, DTL/ER, DTL/ER,
CBK/BNA CBK/BNA CBK/BNA CBK/BNA CBK/BNA
(E.350, (UNI, OSPF, (Sect. (Sect.
SS7) PNNI, BGP, 7.3) 7.3)
AINI, MPLS)
BW-
MODIFY)
State Dep. Rtg. DTL/ER, DTL, ER, BNA DTL/ER, DTL/ER,
CBK/BNA CBK (OSPF, CBK/BNA CBK/BNA
(E.350, (UNI, BGP, (Sect. (Sect.
SS7) PNNI, MPLS) 7.3) 7.3)
AINI,
BW-
MODIFY)
Event Dep. Rtg. DTL/ER, DTL/ER, DTL/ER, DTL/ER, DTL/ER,
CBK/BNA CBK/BNA CBK/BNA CBK/BNA CBK/BNA
(E.350, (UNI, OSPF, (Sect. (Sect.
SS7) PNNI, BGP, 7.3) 7.3)
AINI, MPLS)
BW-
MODIFY)
--------------------------------------------------------------------
QoS Resource BW Allocation QoS- QoS- QoS- QoS- QoS-
Resource & Protection PAR, PAR, PAR, PAR, PAR
TRAF- TRAF- TRAF- TRAF- TRAF-
PAR, PAR, PAR, PAR, PAR,
DoS, DoS, DoS, DoS, DoS,
MOD MOD MOD MOD MOD
(Sect. (UNI, (OSPF, (Sect. (Sect.
7.4) PNNI, BGP, 7.4) 7.4)
AINI, MPLS)
BW-
MODIFY)
Priority Rtg. DoS DoS DoS DoS DoS
(Sect. (UNI, (OSPF, (Sect. (Sect.
7.4) PNNI, BGP, 7.4) 7.4)
AINI, MPLS)
BW-
MODIFY)
Priority N/A DIFF- DIFF- DIFF- DIFF-
SERV SERV SERV SERV
(UNI, (OSPF, (Sect. (Sect.
PNNI, BGP, 7.4) 7.4)
AINI, MPLS)
BW-
MODIFY)
--------------------------------------------------------------------
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 25]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
These information-exchange methods are recommended for use within each
network type and for interworking across network types. Therefore it is
recommended that all information-exchange parameters identified in Table 4
be supported by the standards identified in the table, for each of the five
network technologies. That is, it is recommended that standards be
developed for all information-exchange parameters not currently supported,
which are identified in Table 4 as References to Sections of this
Recommendation. This will ensure information-exchange compatibility when
interworking between the TDM-, ATM-, and IP-based network types, as denoted
in the left three network technology columns. To support this
information-exchange interworking across network types, it is further
recommended that the information exchange at the interface be compatible
across network types. Standardizing the recommended information routing
methods and information-exchange parameters also supports the network
technology cases in the right two columns of Table 4, in which PSTNs
incorporate ATM- or IP-based technology
We first discuss the routing methods identified by the rows of Table 4, and
we then discuss the harmonization of PSTN/ATM-Based and PSTN/IP-Based
information exchange, as identified by columns 4 and 5 of Table 4. In
Sections 7.1 to 7.4, we describe, respectively the number
translation/routing, routing-table-management, route selection, and QoS
resource management information-exchange parameters recommended in Table 4.
In Section 7.5, we discuss the harmonization of routing methods standards
for the two technology cases in the right two columns of Table 4, in which
PSTNs incorporate ATM- or IP-based technology.
7.1 Number Translation/Routing Information-Exchange Parameters
In the Recommendation we assume the separation of call-control signaling for
call establishment from connection/bandwidth-allocation-control signaling
for bearer-channel establishment. Call-control signaling protocols are
described for example in [Q.2761] for the Broadband ISDN Used Part (B-ISUP)
signaling protocol, [ATM990048, T1S198] for ISUP+ virtual trunking, [H.323]
for the H.323 protocol, [GR99] for the media gateway control [MEGACO]
protocol, and in [HSSR99] for the session initiation protocol (SIP).
Connection control protocols are described in ANNEX A-C, and include for
example [Q.2761] for B-ISUP signaling, [ATM960055] for PNNI signaling,
[ATM960061] for UNI signaling, [DN99] for switched virtual path (SVP)
signaling, and [J99] for MPLS constraint-based routing label distribution
protocol (CRLDP) signaling.
As discussed in Section 6.1, number (or name) translation should result in
the E.164 NSAP addresses, INRAs, and/or IP addresses. It is recommended
that provision be made for carrying E.164-NSAP addresses, INRAs, and IP
addresses in the connection-setup IE. When this is the case, then
E.164-NSAP addresses, INRAs, and IP addresses will become the standard
addressing method for interworking across TDM-, ATM-, and IP-based networks.
In addition, it is recommended that a call identification code (CIC) be
carried in the call-control and bearer-control connection-setup IEs in order
to correlate the call-control setup with the bearer-control setup,
[ATM990048, T1S198]. Carrying these additional parameters in the Signaling
System 7 (SS7) ISDN User Part (ISUP) connection-setup IEs is sometimes
referred to as the ISUP+ virtual trunking protocol or bearer independent
call control (BICC) protocol.
As shown in Table 4, it is recommended that provision be made for carrying
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 26]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
E.164-NSAP addresses, INRAs, and IP addresses in the connection-setup IE.
In particular, it is recommended that E.164-NSAP-address, INRA, and
IP-address elements be developed within IP-based and PSTN/IP-based networks.
As discussed in Section 6.2 and shown in Table 1, it is recommended that
number translation/routing methods supported by these parameters be
developed for IP-based and PSTN/IP-based networks. When this is the case,
then E.164-NSAP addresses, INRAs, and IP addresses will become the standard
addressing method for interworking across TDM-, ATM-, and IP-based networks.
7.2 Routing Table Management Information-Exchange Parameters
Routing table management information is used for purposes of applying the
routing table design rules for determining route choices in the routing
table. This information is exchanged between one node and another node,
such as between the ON and DN, for example, or between a node and a network
element such as a routing processor (RP). This information is used to
generate the routing table, and then the routing table is used to determine
the route choices used in the selection of a route.
In order to achieve automatic update and synchronization of the topology
database, which is essential for routing table design, ATM- and IP-based
based networks already interpret HELLO protocol mechanisms to identify links
in the network. For topology database synchronization the PNNI
topology-state-element (PTSE) exchange is used in ATM-based networks and
link state advertisement (LSA) is used in IP-based networks to automatically
provision nodes, links, and reachable addresses in the topology database.
Hence these parameters are recommended for this function:
1. HELLO parameter: Provides for the identification of links between
nodes in the network.
2. Topology-state-element (TSE) parameter: Provides for the automatic
updating of nodes, links, and reachable addresses in the topology database.
These information exchange parameters are already deployed in ATM- and
IP-based network implementations, and are recommended to be extended to
TDM-based network environments.
The following parameters are recommended for the status query and routing
recommendation function:
3. Routing-query-element (RQE) parameter: Provides for an ON to DN or
ON to RP link and/or node status request.
4. Routing-status-element (RSE) parameter: Provides for a node to RP
or DN to ON link and/or node status information.
5. Routing-recommendation-element (RRE) parameter: Provides for an RP
to node routing recommendation.
These information exchange parameters are being standardized with
Recommendation [E.350], and are recommended to be extended to ATM- and
IP-based network environments.
As shown in Table 4, it is recommended that a TSE parameter be developed
within TDM-based PSTN networks. As discussed in Section 6.2 and shown in
Table 1, it is recommended that topology update routing methods supported by
these parameters be developed for PSTN/TDM-based networks. When this is the
case, then the HELLO and TSE/PTSE/LSA parameters will become the standard
topology update method for interworking across TDM-, ATM-, and IP-based
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 27]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
networks.
As shown in Table 4, it is recommended that a RSE parameter be developed
within TDM-based networks, which will be compatible with the PTSE parameter
in ATM-based networks and the LSA parameter in IP-based networks. As
discussed in Section 6.2 and shown in Table 1, it is recommended [E.350]
that status update routing methods supported by these parameters be
developed for TDM-based networks. When this is the case, then the
RSE/PTSE/LSA parameters will become the standard status update method for
interworking across TDM-, ATM-, and IP-based networks.
As shown in Table 4, it is recommended that a RQE parameter be developed
within ATM-based, IP-based, PSTN/ATM-based, and PSTN/IP-based networks. As
discussed in Section 6.2 and shown in Table 1, it is recommended that
query-for-status routing methods supported by these parameters be developed
for ATM-based, IP-based, PSTN/ATM-based, and PSTN/IP-based networks. When
this is the case, then the RQE parameters will become the standard query for
status method for interworking across TDM-, ATM-, and IP-based networks.
As shown in Table 4, it is recommended that a RRE parameter be developed
within ATM-based, IP-based, PSTN/ATM-based, and PSTN/IP-based networks. As
discussed in Section 6.2 and shown in Table 1, it is recommended that
routing-recommendation methods be developed supported by these parameters
for ATM-based, IP-based, PSTN/ATM-based, and PSTN/IP-based networks. When
this is the case, then the RRE parameters will become the standard query for
status method for interworking across TDM-, ATM-, and IP-based networks.
7.3 Route Selection Information-Exchange Parameters
Connection/bandwidth-allocation control information is used to seize
bandwidth on links in a route, to release bandwidth on links in a route, and
for purposes of advancing route choices in the routing table. Existing
connection/bandwidth-allocation setup and connection-release IEs, as
described in [Q.2761, ATM960055, ATM960061, DN99, J99], can be used with
additional parameters to control SVC/SVP/CRLDP route routing, DoS
bandwidth-allocation thresholds, and crankback/bandwidth-not-available to
allow further alternate routing. Actual selection of a route is determined
from the routing table, and connection/bandwidth-allocation control
information is used to establish the route choice.
Source routing can be implemented through the use of
connection/bandwidth-allocation control signaling methods employing the
designated-transit-list (DTL) or explicit-route (ER) parameter in the
connection-setup (IAM, SETUP, MODIFY REQUEST, and LABEL REQUEST) IE and the
crankback (CBK)/bandwidth-not-available (BNA) parameter in the
connection-release (RELEASE, MODIFY REJECT, and NOTIFY) IE. The DTL or ER
parameter specifies all VNs and DN in a route, as determined by the ON, and
the crankback/bandwidth-not-available parameter allows a VN to return
control of the connection request to the ON for further alternate routing.
Forward information exchange is used in connection/bandwidth-allocation
setup, and includes for example the following parameters:
6. Setup with designated-transit list/explicit-route (DTL/ER)
parameter: The DTL parameter in PNNI or the ER parameter in CRLDP specifies
each VN and the DN in the route, and is used by each VN to determine the
next node in the route.
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 28]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
Backward information exchange is used to release a
connection/bandwidth-allocation request on a link such as from a DN to a VN
or from a VN to an ON, and the following parameters are recommended:
7. Release with crankback/bandwidth-not-available (CBK/BNA) parameter:
The CBK/BNA parameter in the connection-release IE is sent from the VN to ON
or DN to ON, and allows for possible further alternate routing at the ON.
It is recommended that the CBK/BNA parameter be included (as appropriate) in
the RELEASE IE for TDM-based networks, the SVC RELEASE and SVP MODIFY REJECT
IE for ATM-based networks, and CRLDP NOTIFY IE for IP-based networks. This
parameter is used to allow the ON to search out additional bandwidth on
additional SVC/SVP/CRLSPs.
As shown in Table 4, it is recommended that the DTL/ER and CBK/BNA elements
be developed within TDM-based networks, which will be compatible with the
DTL element in ATM-based networks and the ER element in IP-based networks.
As discussed in Section 6.3 and shown in Table 1, it is recommended [E.350]
that route-selection methods be developed supported by these parameters for
TDM-based networks. Furthermore it is recommended that TDR and EDR
route-selection methods be developed supported by these parameters for
ATM-based, IP-based, PSTN/ATM-based, and PSTN/IP-based networks. When this
is the case, then the DTL/ER and CBK/BNA parameters will become the standard
route-selection method for interworking across TDM-, ATM-, and IP-based
networks.
7.4 QoS Resource Management Information-Exchange Parameters
QoS resource management information is used to provide differentiated
service priority in seizing bandwidth on links in a route and also in
providing queuing resource priority. These parameters are recommended:
8. Setup with QoS parameters (QoS-PAR): The QoS-PAR include QoS
thresholds such as transfer delay, delay variation, and packet loss. The
QoS-PAR parameters are used by each VN to compare the link QoS performance
to the requested QoS threshold to determine if the
connection/bandwidth-allocation request is admitted or blocked on that link.
9. Setup with traffic parameters (TRAF-PAR): The TRAF-PAR include
traffic parameters such as average bit rate, maximum bit rate, and minimum
bit rate. The TRAF-PAR parameters are used by each VN to compare the link
traffic characteristics to the requested TRAF-PAR thresholds to determine if
the connection/bandwidth-allocation request is admitted or blocked on that
link.
10. Setup with depth-of-search (DoS) parameter: The DoS parameter is
used by each VN to compare the load state on the link to the allowed DoS to
determine if the connection/bandwidth-allocation request is admitted or
blocked on that link.
11. Setup with modify (MOD) parameter: The MOD parameter is used by each
VN to compare the requested modified traffic parameters on an existing
SVP/CRLSP to determine if the modification request is admitted or blocked on
that link.
12. Differentiated services (DIFFSERV) parameter: The DIFFSERV parameter
is used in ATM-based and IP-based networks to support priority queuing. The
DIFFSERV parameter is used at the queues associated with each link to
designate the relative priority and management policy for each queue.
It is recommended that the QoS-PAR, TRAF-PAR, DTL/ER, DoS, MOD, and DIFFSERV
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 29]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
parameters be included (as appropriate) in the initial address message (IAM)
for TDM-based networks, the SVC/SVP SETUP IE and SVP MODIFY REQUEST IE for
ATM-based networks, and CRLDP LABEL REQUEST IE for IP-based networks. These
parameters are used to control the routing, bandwidth allocation, and
routing/queuing priorities.
As shown in Table 4, it is recommended that the QoS-PAR and TRAF-PAR
elements be developed within TDM-based networks to support bandwidth
allocation and protection, which will be compatible with the QoS-PAR and
TRAF-PAR elements in ATM-based and IP-based networks. In addition, it is
recommended that the DoS element be developed within TDM-based networks,
which will be compatible with the DoS element in ATM-based and IP-based
networks. Finally, it is recommended that the DIFFSERV element should be
developed in ATM-based and IP-based networks to support priority queuing.
As discussed in Section 6.4 and shown in Table 1, it is recommended [E.350]
that QoS-resource-management methods be developed supported by these
parameters for TDM-based networks. When this is the case, then the QoS-PAR,
TRAF-PAR, DoS, and DIFFSERV parameters will become the standard
QoS-resource-management methods for interworking across TDM-, ATM-, and
IP-based networks.
7.5 Harmonization of Information-Exchange Standards
Harmonization of information-exchange standards is needed for the two
technology cases in the right two columns of Table 4, in which PSTNs
incorporate ATM- or IP-based technology. For example, the harmonized
standards pertain to the case when PSTNs such as network B and network C in
Figure 1 incorporate IP- or ATM-based technology. Assuming network B is a
PSTN incorporating IP-based technology, established routing methods and
compatible information-exchange are recommended to be applied. Achieving
this will affect recommendations both with ITU-T and IETF that apply to the
impacted routing and information exchange functions.
Contributions to the ATM Forum and IETF are necessary to address
a) needed number translation/routing functionality, which includes
support for international network routing address and IP address parameters,
b) needed routing table management information-exchange functionality,
which includes query-for-status and routing-recommendation methods,
c) needed route selection information-exchange functionality, which
includes time dependent routing and event dependent routing.
7.6 Open Routing Application Programming Interface (API)
Application programming interfaces (APIs) are being developed to allow
control of network elements through open interfaces available to individual
applications. APIs allow applications to access and control network
functions including routing policy, as necessary, according to the specific
application functions. The API parameters under application control, such as
those specified for example in [PARLAY], are independent of the individual
protocols supported within the network, and therefore can provide a common
language and framework across various network technologies, such as TDM-,
ATM-, and IP-based technologies.
The signaling/information-exchange connectivity management parameters
specified in this Section which need to be controlled through an
applications interface include QoS-PAR, TRAF-PAR, DTL/ER, DoS, MOD,
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 30]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
DIFFSERV, E.164-NSAP, INRA, CIC, and perhaps others. The
signaling/information-exchange routing policy parameters specified in this
Section which need to be controlled through an applications interface
include TSE, RQE, RRE, and perhaps others. These parameters are recommended
to be specified within the open API interface for routing functionality, and
in this way applications will be able to access and control routing
functionality within the network independent of the particular routing
protocol(s) used in the network.
8.0 Examples of Internetwork Routing
A network consisting of various subnetworks using different routing
protocols is considered in this Recommendation. For example, as illustrated
in Figure 4, consider a network with four subnetworks denoted as networks A,
B, C, and D, where each network uses a different routing protocol. In this
example, network A is an ATM-based network which uses PNNI EDR route
selection, network B is a TDM-based network which uses centralized periodic
SDR route selection, network C is an IP-based network which uses MPLS EDR
route selection, and network D is a TDM-based network which uses TDR route
selection. Internetwork E is defined by the shaded nodes in Figure 4 and is
a virtual network where the interworking between networks A, B, C, and D is
actually taking place.
<>
Figure 4. Example of an Internetwork Routing Scenario. RPb denotes a
routing processor in network B for a centralized periodic SDR method. The
set of shaded nodes is internetwork E for routing of
connection/bandwidth-allocation requests between networks A, B, C, and D.
8.1 Internetwork E Uses a Mixed Route Selection Method
Internetwork E can use various route selection methods in delivering
connection/bandwidth-allocation requests between the subnetworks A, B, C,
and D. For example, internetwork E can implement a mixed route selection
method in which each node in internetwork E uses the route selection method
used in its home subnetwork. Consider a connection/bandwidth-allocation
request from node a1 in network A to node b4 in network B. Node a1 first
routes the connection/bandwidth-allocation request to either node a3 or a4
in network A and in doing so uses EDR route selection. In that regard node
a1 first tries to route the connection/bandwidth-allocation request on the
direct link a1-a4, and assuming that link a1-a4 bandwidth is unavailable
then selects the current successful route a1-a3-a4 and routes the
connection/bandwidth-allocation request to node a4 VN a3. In so doing node
a1 and node a3 put the DTL/ER parameter (identifying ON a1, VN a3, and DN
a4) and QoS-PAR, TRAF-PAR, DoS, and DIFFSERV parameters in the
connection/bandwidth-allocation request connection-setup IE.
Node a4 now proceeds to route the connection/bandwidth-allocation request to
node b1 in subnetwork B using EDR route selection. In that regard node a4
first tries to route the connection/bandwidth-allocation request on the
direct link a4-b1, and assuming that link a4-b1 bandwidth is unavailable
then selects the current successful route a4-c2-b1 and routes the
connection/bandwidth-allocation request to node b1 VN c2. In so doing node
a4 and node c2 put the DTL/ER parameter (identifying ON a4, VN c2, and DN
b1) and QoS-PAR, TRAF-PAR, DoS, and DIFFSERV parameters in the
connection/bandwidth-allocation request connection-setup IE.
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 31]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
If node c2 finds that link c2-b1 does not have sufficient available
bandwidth, it returns control of the connection/bandwidth-allocation request
to node a4 through use of a CBK/BNA parameter in the connection-release IE.
If now node a4 finds that link d4-b1 has sufficient idle bandwidth capacity
based on the RSE parameter in the status response IE from node b1, then node
a4 could next try route a4-d3-d4-b1 to node b1. In that case node a4 routes
the connection/bandwidth-allocation request to node d3 on link a4-d3, and
node d3 is sent the DTL/ER parameter (identifying ON a4, VN d3, VN d4, and
DN b1) and the DoS parameter in the connection-setup IE. In that case node
d3 tries to seize idle bandwidth on link d3-d4, and assuming that there is
sufficient idle bandwidth routes the connection/bandwidth-allocation request
to node d4 with the DTL/ER parameter (identifying ON a4, VN d3, VN d4, and
DN b1) and the QoS-PAR, TRAF-PAR, DoS, and DIFFSERV parameters in the
connection-setup IE. Node d4 then routes the
connection/bandwidth-allocation request on link d4-b1 to node b1, which has
already been determined to have sufficient idle bandwidth capacity. If on
the other hand there is insufficient idle d4-b1 bandwidth available, then
node d3 returns control of the call to node a4 through use of a CRK/BNA
parameter in the connection-release IE. At that point node a4 may try
another multilink route, such as a4-a3-b3-b1, using the same procedure as
for the a4-d3-d4-b1 route.
Node b1 now proceeds to route the connection/bandwidth-allocation request to
node b4 in network B using centralized periodic SDR route selection. In that
regard node b1 first tries to route the connection/bandwidth-allocation
request on the direct link b1-b4, and assuming that link b1-b4 bandwidth is
unavailable then selects a two-link route b1-b2-b4 which is the currently
recommended alternate route identified in the RRE parameter from the routing
processor (RPb) for network B. RPb bases its alternate routing
recommendations on periodic (say every 10 seconds) link and traffic status
information in the RSE parameters received from each node in network B.
Based on the status information, RPb then selects the two-link route
b1-b2-b4 and sends this alternate route recommendation in the RRE parameter
to node b1 on a periodic basis (say every 10 seconds). Node b1 then routes
the connection/bandwidth-allocation request to node b4 VN b2. In so doing
node b1 and node b2 put the DTL/ER parameter (identifying ON b1, VN b2, and
DN b4) and QoS-PAR, TRAF-PAR, DoS, and DIFFSERV parameters in the
connection/bandwidth-allocation request connection-setup IE.
A connection/bandwidth-allocation request from node b4 in network B to node
a1 in network A would mostly be the same as the
connection/bandwidth-allocation request from a1 to b4, except with all the
above steps in reverse order. The difference would be in routing the
connection/bandwidth-allocation request from node b1 in network B to node a4
in network A. In this case, based on the mixed route selection assumption
in virtual network E, the b1 to a4 connection/bandwidth-allocation request
would use centralized periodic SDR route selection, since node b1 is in
network B, which uses centralized periodic SDR. In that regard node b1
first tries to route the connection/bandwidth-allocation request on the
direct link b1-a4, and assuming that link b1-a4 bandwidth is unavailable
then selects a two-link route b1-c2-a4 which is the currently recommended
alternate route identified in the RRE parameter from the routing processor
(RPb) for virtual network E. RPb bases its alternate routing
recommendations on periodic (say every 10 seconds) link and traffic status
information in the RSE parameters received from each node in virtual
subnetwork E. Based on the status information, RPb then selects the
two-link route b1-c2-a4 and sends this alternate route recommendation in the
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page32]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
RRE parameter to node b1 on a periodic basis (say every 10 seconds). Node
b1 then routes the connection/bandwidth-allocation request to node a4 via VN
c2. In so doing node b1 and node c2 put the DTL/ER parameter (identifying
ON b1, VN c2, and DN a4) and QoS-PAR, TRAF-PAR, DoS, and DIFFSERV parameters
in the connection/bandwidth-allocation request connection-setup IE.
If node c2 finds that link c2-a4 does not have sufficient available
bandwidth, it returns control of the connection/bandwidth-allocation request
to node b1 through use of a CRK/BNA parameter in the connection-release IE.
If now node b1 finds that route b1-d4-d3-a4 has sufficient idle bandwidth
capacity based on the RSE parameters in the status IEs to RPb, then node b1
could next try route b1-d4-d3-a4 to node a4. In that case node b1 routes
the connection/bandwidth-allocation request to node d4 on link b1-d4, and
node d4 is sent the DTL/ER parameter (identifying ON b1, VN d4, VN d3, and
DN a4) and the QoS-PAR, TRAF-PAR, DoS, and DIFFSERV parameters in the
connection-setup IE. In that case node d4 tries to seize idle bandwidth on
link d4-d3, and assuming that there is sufficient idle bandwidth routes the
connection/bandwidth-allocation request to node d3 with the DTL/ER parameter
(identifying ON b1, VN d4, VN d3, and DN a4) and the QoS-PAR, TRAF-PAR, DoS,
and DIFFSERV parameters in the connection-setup IE. Node d3 then routes the
connection/bandwidth-allocation request on link d3-a4 to node a4, which is
expected based on status information in the RSE parameters to have
sufficient idle bandwidth capacity. If on the other hand there is
insufficient idle d3-a4 bandwidth available, then node d3 returns control of
the call to node b1 through use of a CRK/BNA parameter in the
connection-release IE. At that point node b1 may try another multilink
route, such as b1-b3-a3-a4, using the same procedure as for the b1-d4-d3-a4
route.
Allocation of end-to-end performance parameters across networks is addressed
in Recommendation I.356, Section 9. An example is the allocation of the
maximum transfer delay to individual network components of an end-to-end
connection, such as national network portions, international portions, etc.
8.2 Internetwork E Uses a Single Route Selection Method
Internetwork E may also use a single route selection method in delivering
connection/bandwidth-allocation requests between the networks A, B, C, and
D. For example, internetwork E can implement a route selection method in
which each node in internetwork E uses EDR. In this case the example
connection/bandwidth-allocation request from node a1 in network A to node b4
in network B would be the same as described above. A
connection/bandwidth-allocation request from node b4 in network B to node a1
in network A would be the same as the connection/bandwidth-allocation
request from a1 to b4, except with all the above steps in reverse order. In
this case the routing of the connection/bandwidth-allocation request from
node b1 in network B to node a4 in network A would also use EDR in a similar
manner to the a1 to b4 connection/bandwidth-allocation request described
above.
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 33]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
9.0 Authors' Addresses
Gerald R. Ash
AT&T Labs
Room MT E3-3C37
200 Laurel Avenue
Middletown, NJ 07748
Phone: 732-420-4578
Fax: 732-368-6687
Email: gash@att.com
Young Lee
AT&T Labs
Room MT C5-2D20
200 Laurel Avenue
Middletown, NJ 07748
Phone: 732-420-4477
Fax: 732-368-1730
Email: younglee@att.com
ANNEX A - TDM-BASED INTRANETWORK ROUTING METHODS
TDM-based routing methods described in this ANNEX include E.164/NSAP
numbering/addressing methods, automatic routing table generation methods,
dynamic route selection methods, and QoS resource management methods, all of
which have been deployed over the past two decades in TDM-based networks.
This Recommendation suggests that compatible route selection and QoS
resource management methods be extended to ATM-based and IP-based networks
and to interworking between TDM-, ATM-, and IP-based networks.
A.1 TDM-Based Number Translation/Routing
Recommendation E.164 identifies the numbering plan currently used for
TDM-based networks. Recommendation E.191 specifies the B-ISDN address
structure, which has a 20-byte format as shown in Figure A1 below.
<>
The IDP is the initial domain part and the DSP is the domain specific part.
The IDP is further subdivided into the AFI and IDI. The IDI is the initial
domain identifier and can contain the 15-digit E.164 address if the AFI is
set to 45. AFI is the authority and format identifier and determines what
kind of addressing method is followed, and based on the 1 octet AFI value,
the length of the IDI and DSP fields can change. The E.164/network service
access point (NSAP) address is used to determine the route to the
destination endpoint. E.164/NSAP addressing for B-ISDN services is
supported in ATM networks using PNNI, through use of the above NSAP or ATM
end system address (AESA) format. In this case the E.164 part of the NSAP
address occupies the 8 octet IDI, and the 11 octet DSP can be used at the
discretion of the network operator (perhaps for sub-addresses). The above
NSAP structure also supports AESA DCC (data country code) and AESA ICD
(international code designator) addressing formats.
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 34]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
A.2 TDM-Based Routing Table Management & Route Selection
A specific traffic routing method is characterized by the routing table used
in the method. The routing table consists of a route and rules to select
one route from the route for a given connection request. When a connection
request arrives at its ON, the ON implementing the routing method executes
the route selection rules associated with the routing table for the
connection to determine a route among the routes in the route for the
connection request. In a particular routing method, the set of routes
assignable to the connection request may be altered according to a certain
route alteration rule.
A network is operated with progressive connection control, originating
connection control, or a mix of the two control methods. In a network with
progressive connection control, a node selects a route or a link to an
appropriate next node. In a network with originating connection control,
the ON maintains control of the connection. If
crankback/bandwidth-not-available (or automatic rerouting (ARR)) is used,
for example, at a via node (VN), the preceding node maintains control of the
connection even if the connections are blocked on all the links outgoing
from the VN. When networks with progressive connection control and
originating connection control are interworked, the network operates with a
mix of both control methods.
In ITU-T Recommendations E.170, E.177, and E.350, traffic routing methods
are categorized into the following four types based on their routing
pattern: fixed routing (FR), time-dependent routing (TDR), state-dependent
routing (SDR), and event-dependent routing (EDR). We discuss each of these
methods in the following paragraphs.
A.2.1 Fixed Routing (FR)
In a fixed routing (FR) method, a routing pattern is fixed for a connection
request. A typical example of fixed routing is a conventional hierarchical
alternate routing where the route and route selection sequence are
determined on a preplanned basis and maintained over a long period of time.
FR is more efficiently applied when the network is nonhierarchical, or flat,
as compared to the hierarchical structure [A98].
A.2.2 Time-Dependent Routing (TDR)
Time-dependent routing (TDR) methods are a type of dynamic routing in which
the routing tables are altered at a fixed point in time during the day or
week. TDR routing tables are determined on a preplanned basis and are
implemented consistently over a time period. The TDR routing tables are
determined considering the time variation of traffic load in the network.
Typically, the TDR routing tables used in the network are coordinated by
taking advantage of noncoincidence of busy hours among the traffic loads.
Dynamic Nonhierarchical Routing (DNHR) is an example of TDR, which is
illustrated in Recommendation E.350.
In TDR, the routing tables are preplanned and designed off-line using a
centralized design system, which employs the TDR network design model. The
off-line computation determines the optimal routes from a very large number
of possible alternatives, in order to minimize the network cost. The
designed routing tables are loaded and stored in the various nodes in the
TDR network, and periodically recomputed and updated (e.g., every week) by
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 35]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
the off-line system. In this way an ON does not require additional network
information to construct TDR routing tables, once the routing tables have
been loaded. This is in contrast to the design of routing tables in real
time, such as in the state dependent routing and event dependent routing
methods described below. Routes in the TDR routing table may consist of
time varying routing choices and use a subset of the available routes.
Routes used in various time periods need not be the same. Several TDR time
periods are used to divide up the hours on an average business day and
weekend into contiguous routing intervals, sometimes called load set
periods.
Route selection rules employed in TDR routing tables, for example, may
consist of simple sequential routing. In the sequential method all traffic
in a given time period is offered to a single route, and lets the first
route in the route overflow to the second route which overflows to the third
route, and so on. Thus, traffic is routed sequentially from route to route,
and the route is allowed to change from hour to hour to achieve the
preplanned dynamic, or time varying, nature of the TDR method. Other TDR
route selection rules can employ probabilistic techniques to select each
route in the route and thus influence the realized flows [A98].
Routes in the TDR routing table may consist of the direct link, a two-link
route through a single VN, or a multiple-link route through multiple VNs.
Routes in the routing table are subject to depth-of-search (DoS)
restrictions, as described in the next Section A.3. DoS requires that the
bandwidth capacity available on each link in the route be sufficient to meet
a DoS bandwidth threshold level, which is passed to each node in the route
in the setup message. DoS restrictions prevent connections that route on
the first choice (shortest) ON-DN route, for example, from being swamped by
alternate routed multiple-link connections.
A TDR connection set-up example is now given. The first step is for the
node to identify the DN and routing table information to the DN. The ON
then tests for spare capacity on the first or shortest route, and in doing
this supplies the VNs and DN on this route, along with the DoS parameter, to
all nodes in the route. Each VN tests the available bandwidth capacity on
each link in the route against the DoS threshold. If there is sufficient
capacity, the VN forwards the connection setup to the next node, which
performs a similar function. If there is insufficient capacity, the VN
sends a release message with crankback/bandwidth-not-available parameter
back to the ON, at which point the ON tries the next route in the route as
determined by the routing table rules. As described above, the TDR routes
are preplanned, loaded, and stored in each ON
A.2.3 State-Dependent Routing (SDR)
In state-dependent routing (SDR), the routing tables are altered
automatically according to the state of the network. For a given SDR
method, the routing table rules are implemented to determine the route
choices in response to changing network status, and are used over a
relatively short time period. Information on network status may be
collected at a central processor or distributed to nodes in the network.
The information exchange may be performed on a periodic or on-demand basis.
SDR methods use the principle of routing connections on the best available
route on the basis of network state information. For example, in the least
loaded routing (LLR) method, the residual capacity of candidate routes is
calculated, and the route having the largest residual capacity is selected
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 36]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
for the connection. In general, SDR methods calculate a route cost for each
connection request based on various factors such as the load-state or
congestion state of the links in the network. dynamically controlled
routing (DCR), worldwide intelligent network (WIN) routing, and real-time
network routing (RTNR) are examples of SDR, which are illustrated in
Recommendation E.350.
In SDR, the routing tables are designed on-line by the ON or a central
routing processor (RP) through the use of network status and topology
information obtained through information exchange with other nodes and/or a
centralized RP. There are various implementations of SDR distinguished by
a) whether the computation of the routing tables is distributed among
the network nodes or centralized and done in a centralized RP, and
b) whether the computation of the routing tables is done periodically
or connection by connection.
This leads to three different implementations of SDR:
a) centralized periodic SDR -- here the centralized RP obtains link status
and traffic status information from the various nodes on a periodic basis
(e.g., every 10 seconds) and performs a computation of the optimal routing
table on a periodic basis. To determine the optimal routing table, the RP
executes a particular routing table optimization procedure such as LLR and
transmits the routing tables to the network nodes on a periodic basis (e.g.,
every 10 seconds). DCR is an example of centralized periodic SDR, as
illustrated in E.350.
b) distributed periodic SDR -- here each node in the SDR network obtains
link status and traffic status information from all the other nodes on a
periodic basis (e.g., every 5 minutes) and performs a computation of the
optimal routing table on a periodic basis (e.g., every 5 minutes). To
determine the optimal routing table, the ON executes a particular routing
table optimization procedure such as LLR. WIN is an example of distributed
periodic SDR, as illustrated in E.350.
c) distributed call-by-call SDR -- here an ON in the SDR network obtains
link status and traffic status information from the DN, and perhaps from
selected VNs, on a connection by connection basis and performs a computation
of the optimal routing table for each connection. To determine the optimal
routing table, the ON executes a particular routing table optimization
procedure such as LLR. RTNR is an example of distributed
connection-by-connection SDR, as illustrated in E.350.
Routes in the SDR routing table may consist of the direct link, a two-link
route through a single VN, or a multiple-link route through multiple VNs.
Routes in the routing table are subject to DoS restrictions on each link,
and the connection setup mechanisms are similar to the example given in
Section A.2.2.
A.2.4 Event-Dependent Routing (EDR)
In event-dependent routing (EDR), the routing tables are updated locally on
the basis of whether connections succeed or fail on a given route choice.
In EDR, a connection is routed first to the shortest route, if it has
sufficient available bandwidth. Otherwise, overflow from the shortest route
is offered to a currently selected alternate route. If a connection is
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 37]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
blocked on the current alternate route choice, another alternate route is
selected from a set of available alternate routes for the connection request
according to the given EDR routing table rules. For example, the current
alternate route choice can be updated randomly, cyclically, or by some other
means, and may be maintained as long as a connection can be established
successfully on the route. Note that for either SDR or EDR, as in TDR, the
alternate route for a connection request may be changed in a time-dependent
manner considering the time-variation of the traffic load. Dynamic
alternate routing (DAR), distributed adaptive dynamic routing (DADR),
optimized dynamic routing (ODR), and state- and time-dependent routing (STR)
are examples of event-dependent routing, which are illustrated in
Recommendation E.350.
In EDR, the routing tables are designed by the ON using network information
obtained during the connection setup function. Typically the ON first
selects the shortest route, and if that has insufficient bandwidth for the
connection then the current successful via route is tried. If the current
successful via route has insufficient bandwidth, this condition is indicated
by a busy ON-VN link as determined by the ON or a busy VN-VN link or VN-DN
link as indicated by a release message sent from the VN to the ON. At that
point the ON selects a new via route using the given EDR routing table
design rules. Hence the routing table is constructed with the information
determined during connection setup, and no additional information is
required by the ON.
Routes in the EDR routing table may consist of the direct link, a two-link
route through a single VN, or a multiple-link route through multiple VNs.
Routes in the routing table are subject to DoS restrictions on each link,
and the connection setup mechanisms are similar to the example given in
Section A.2.2.
A.3 TDM-Based QoS Resource Management
See Section 6.4 for a discussion of the recommended QoS resource management
methods.
ANNEX B - ATM-BASED INTRANETWORK ROUTING METHODS
In ATM networks the private network-to-network interface (PNNI) standard
adopted by the ATM Forum [ATM960055] provides for a) exchange of node and
link status information, b) automatic update and synchronization of topology
databases, c) fixed and/or dynamic route selection based on topology and
status information, and d) signaling and information exchange standards.
PNNI is a standardized signaling and dynamic routing strategy for ATM
networks adopted by the ATM Forum in 1996 [ATM960055]. PNNI provides
interoperability among different vendor equipment and scaling to very large
networks. Scaling is provided by a hierarchical peer group structure that
allows the details of topology of a peer group to be flexibly hidden or
revealed at various levels within the hierarchical structure. Peer group
leaders represent the nodes within a peer group for purposes of routing
protocol exchanges at the next higher level. Border nodes handle
inter-level interactions at call setup. PNNI routing involves two
components: a topology distribution protocol and the route selection and
crankback/bandwidth-not-available procedures. The topology distribution
protocol floods information within a peer group. The peer group leader
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 38]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
abstracts the information from within the peer group and floods the
abstracted topology information to the next higher level in the hierarchy,
including aggregated reachable address information. As the peer group
leader learns information at the next higher level, it floods it to the
lower level in the hierarchy, as appropriate. In this fashion, all nodes
learn of network-wide reachability and topology.
Automatic update and synchronization of topology database methods,
information exchange methods, and connection/bandwidth-allocation control
signaling methods have been deployed over the past two decades in ATM
networks, and this Recommendation suggests that compatible topology database
synchronization, information exchange, and connection/bandwidth-allocation
control signaling methods be extended to TDM- and IP-based networks and to
interworking between TDM-, ATM-, and IP-based networks. For topology
database synchronization, each node in an ATM/PNNI network exchanges HELLO
packets with its immediate neighbors and thereby determines its local state
information. This state information includes the identity and peer group
membership of the node's immediate neighbors, and the status of its links to
the neighbors. Each node then bundles its state information in PNNI topology
state elements (PTSEs), which are reliably flooded throughout the peer
group. The PTSEs are used to flood node information, link state
information, and reachability information.
Some of the topology state information is static and some is dynamic. For
example, static information may consist of the existence of a link, and
dynamic information may refer to the available bandwidth on a link.
Depending on how the dynamic topology state information is used, the maximum
peer group size, as measured by the number of nodes and links may be limited
if PTSEs swamp the ability of the nodes to process
connection/bandwidth-allocation requests. In order to allow larger peer
group sizes, a network can use PNNI in such a way so as to minimize the
amount of dynamic topology state information flooding by setting thresholds
such as the AvCR_PM (average cell rate proportional multiplier) to 99
instead of the default value of 50, and AvCR_mT (average cell rate minimum
threshold) to 99 instead of the default value of 3. Reachability information
is exchanged between all nodes. To provision a new E.164 number, the node
serving that E.164 number is provisioned. The reachability information is
then flooded to all the nodes in the network using the PNNI PTSE flooding
mechanism. A peer group in PNNI is defined at a given hierarchical level.
Multiple hierarchical levels are permitted within an ATM/PNNI network, and
multiple peer groups can be defined at each level
B.1 ATM-Based Number Translation/Routing
ITU-T Recommendation E.191 specifies the ATM network numbering, and as
discussed in ANNEX A.1 provides for the embedded E.164/NSAP formats, which
are desirable for use in B-ISDN.
B.2 ATM-Based Routing Table Management & Route Selection
PNNI route selection is source-based in which the ON determines the
high-level route through the network. The ON performs number translation,
screening, service processing, and all steps necessary to determine the
routing table for the connection/bandwidth-allocation request across the ATM
network. The node places the selected route in the DTL and passes the DTL to
the next node in the SETUP message. The next node does not need to perform
number translation on the called party number but just follows the route
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 39]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
specified in the DTL. When a connection/bandwidth-allocation request is
blocked due to network congestion, a PNNI crankback/bandwidth-not-available
is sent to the first ATM node in the peer group. The first ATM node may
then use the PNNI alternate routing after crankback/bandwidth-not-available
capability to select another route for the connection/bandwidth-allocation
request. If the network is flat, that is, all nodes have the same peer
group level, the ON controls the edge-to-edge route. If the network has
more than one level of hierarchy, as the call progresses from one peer group
into another, the border node at the new peer group selects a route through
that peer group to the next peer group downstream, as determined by the ON.
This occurs recursively through the levels of hierarchy. If at any point
the call is blocked, for example when the selected route bandwidth is not
available, then the call is cranked back to the border node or ON for that
level of the hierarchy and an alternate route is selected. The route
selection algorithm is not stipulated in the PNNI specification, and each ON
implementation can make its own route selection decision unilaterally.
Since route selection is done at an ON, each ON makes route selection
decisions based on its local topology database and specific algorithm. This
means that different route selection algorithms from different vendors can
interwork with each other.
In the PNNI routing example illustrated in Figure B1, an ON S1 determines a
list of shortest routes by using, for example, Dijsktra's algorithm. This
route list could be determined based on administrative weights of each link
which are communicated to all nodes within the peer group through the PTSE
flooding mechanism. These administrative weights may be set, for example,
to 1 + epsilon x distance, where epsilon is a factor giving a relatively
smaller weight to the distance in comparison to the hop count. The ON then
selects a route from the list based on any of the methods described in
Section B.1, that is FR, TDR, SDR, and EDR, as described in ANNEX A.2. For
example, in using the first choice route, the ON S1 sends a PNNI setup
message to VN S2, which in turn forwards the PNNI setup message to VN S3,
and finally to DN S4. The VNs S2 and S3 and DN S4 are passed in the DTL
parameter contained in the PNNI setup message. Each node in the route reads
the DTL information, and passes the PNNI setup message to the next node
listed in the DTL.
<>
If the first route is blocked at any of the links in the route, or overflows
or is excessively delayed at any of the queues in the route, a
crankback/bandwidth-not-available message is returned to the ON which can
then attempt the next route. If FR is used, then this route is the next
route in the shortest route list, for example route S1-S6-S7-S8-S4. If TDR
is used, then the next route is the next route in the routing table for the
current time period. If SDR is used, PNNI implements a distributed method
of flooding link status information, which is triggered either periodically
and/or by crossing load state threshold values. As described in the
beginning of this Section, this flooding method of distributing link status
information can be resource intensive and indeed may not be any more
efficient than simpler route selection methods such as EDR. If EDR is used,
then the next route is the last successful route, and if that route is
unsuccessful another alternate route is searched out according to the EDR
route selection method.
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 40]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
B.3 ATM-Based QoS Resource Management
The methods described in Section 6.4 are applicable to ATM-based networks
since they have been generalized for the ATM B-ISDN protocols, and have been
recommended for ATM-based network standards [AM99]. As discussed in Section
6.4 and [AM99], the DoS parameter is carried in the CCS IAM, or in this case
in the PNNI SETUP message, so that each VN can compare the load state on the
link to the allowed DoS threshold to determine if the
connection/bandwidth-allocation request is admitted or blocked on that link.
QoS resource management methods have been applied successfully in TDM-based
networks over the past decade [A98], have been studied for extension to
ATM-based networks [ACFM99], and are recommended in [AM99] for QoS resource
management in ATM networks employing UNI, PNNI, (and potentially AINI)
protocols. In the recommended QoS resource management method, bandwidth is
allocated to each of 5 virtual networks (VNs) corresponding to constant bit
rate (CBR) and variable bit rate (VBR) high-priority key services, CBR and
VBR normal-priority services, and unassigned bit rate (UBR) best-effort
low-priority services. Examples of services within these VN categories
include a) high-priority key priority services such as CBR defense voice
communication, b) normal-priority services such as CBR interactive,
delay-sensitive voice; VBR interactive, delay-sensitive IP-telephony; and
VBR non-interactive, non-delay-sensitive WWW file transfer, and c)
low-priority best effort services such as UBR non-interactive,
non-delay-sensitive voice mail, email, and file transfer. Bandwidth changes
in VN bandwidth capacity are determined by edge nodes based on bandwidth
demand for VN capacity. Based on the bandwidth demand, these edge nodes
make changes in bandwidth allocation, that is, either increase or decrease
bandwidth on the switched virtual paths (SVPs) constituting the VN bandwidth
capacity. An earlier contribution specified example methods for SVC-based
QoS resource management [AM98].
In [AM99] we recommend that the bandwidth allocation control for each VN be
based on estimated bandwidth needs, bandwidth use, and status of links in
the SVP. The edge node, or originating node (ON), determines when VN
bandwidth needs to be increased or decreased on an SVP, and uses a
recommended SVP bandwidth modification procedure to execute needed bandwidth
allocation changes on VN SVPs. In the bandwidth allocation procedure the
SVP modification protocol [DN99] is used to specify appropriate parameters
in the SVP modify request message a) to request bandwidth allocation changes
on each link in the SVP, and b) to determine if link bandwidth can be
allocated on each link in the SVP. The SVP modify request message allows
dynamic modification of the assigned traffic parameters (such as peak data
rate, committed data rate, etc.) of an already existing SVP. We recommend
an optional depth-of-search (DoS) parameter in the SVP modify request
message (or SVC SETUP message [AM98]) to control the bandwidth allocation
priority on individual links in an SVP (or SVC). If a link bandwidth
allocation is not allowed, the SVP modify reject message with a recommended
bandwidth-not-available parameter allows the ON to search out possible
additional bandwidth allocation on another SVP. This allows the edge node
to search out additional SVPs when a given SVP cannot accommodate a
bandwidth increase request. The DoS parameter is also used to set queuing
priorities on the SVPs constituting the 5 VNs.
In the recommended method of QoS resource management, the admission control
for bandwidth modification on each VN SVP is based on the status of the
links in the SVP. The ON may select any SVP for which the first link is
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 41]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
allowed according to QoS resource management criteria. If a subsequent link
is not allowed, then the SVP modify reject message with a recommended
bandwidth-not-available parameter is used to return to the ON and select an
alternate SVP. Determination of the link load states is necessary for QoS
resource management to select network capacity on either the first choice
SVP or alternate SVPs. Four link load states are distinguished: lightly
loaded (LL), heavily loaded (HL), reserved (R), and busy (B). Management of
VN capacity uses a link state model and a depth-of-search (DoS) model to
determine if a bandwidth modification request can be accepted on a given
SVP. The allowed DoS load state threshold determines if a bandwidth
modification request can be accepted on a given link to an available
bandwidth "depth."
In setting up the bandwidth modification request, the ON encodes the DoS
load state threshold allowed on each link in the recommended DoS parameter
in the SVP modify request (or SVC SETUP). If a link is encountered at a via
node (VN) in which the idle link bandwidth and link load state are below the
allowed DoS load state threshold, then the VN sends a SVP modify reject
message with a recommended bandwidth-not-available parameter to the ON,
which can then route the bandwidth modification request to an additional SVP
choice to increase the overall VN bandwidth allocation of the ON to DN pair.
For example, in Figure 2, SVP A-B-E may be the first route tried where link
A-B is in the LL state and link B-E is in the R state.
If the DoS load state allowed is HL or better, then the SVP bandwidth
modification request in the SVP modify request message is routed on link A-B
but will not be admitted on link B-E, wherein the SVP bandwidth modification
request will be returned in the SVP modify reject message to the originating
node A to try to add another SVP A-C-D-E. Here the SVP bandwidth
modification request succeeds since all links have a state of HL or better.
Hence SVP A-C-D-E is then used in addition to SVP A-B-E to accommodate the
needed A to E bandwidth requirement.
The DoS load state threshold is a function of bandwidth-in-progress, VNET
priority, and bandwidth allocation thresholds [AM98, ACFM99], as follows:
Table B1
Determination of Depth-of-Search (DoS) Load State Threshold
------------------------------------------------------------------------------
Load State Key Normal Priority VN Best Effort
Allowed Priority VN ---------------------------------- Priority VN
First Choice SVP Alternate SVP
------------------------------------------------------------------------------
R if BWIPi <= if BWIPi <= BWavgi Not Allowed Note 1
2 * BWmaxi
HL if BWIPi <= if BWIPi <= BWmaxi if BWIPi <= Note 1
2 * BWmaxi BWavgi
LL All BWIPi All BWIPi All BWIPi Note 1
where
BWIPi = bandwidth-in-progress on VN i
BWavgi = minimum guaranteed bandwidth required for VN
i to carry the
average offered bandwidth load
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 42]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
BWmaxi = the bandwidth required for VN i to meet the
blocking probability grade-of-service
objective
for SVP bandwidth allocation requests
= 1.1 x BWavgi
Note 1 = SVPs for the best effort priority VN are
allocated zero bandwidth; Diffserv queuing
admits
best effort packets only if there is
available
bandwidth on a link
Note that the QoS resource management method provides for a key-priority CBR
and VBR VN, a normal-priority CBR and VBR VN, and a low-priority UBR best
effort VN. Key services admitted by an ON on the key-priority VNs are given
higher priority routing treatment by allowing greater route selection DoS
than normal services admitted on the normal-priority VNs. Best effort
services admitted on the low-priority best effort VN are given lower
priority routing treatment by allowing lesser route selection DoS than
normal. The quantities BWavgi are computed periodically, such as every week
w, and can be exponentially averaged over a several week period. The
determination of these parameters can be implementation specific. Please
refer to [AM98], [ACFM99], and [A98] for further discussion of DoS parameter
and link load state parameter determination.
[AM98] and [ACFM99] discuss the application to SVC-based QoS resource
management. Analogous concepts are used for a DoS controlled call admission
control (CAC) procedure for SVCs.
In addition to the QoS bandwidth management procedure for bandwidth
allocation requests, a QoS priority of service queuing capability is used
during the time connection/bandwidth-allocation requests are established on
each of the 5 VNs. At each link, a queuing discipline is recommended such
that the packets being served are given priority in the following order: key
VN services, normal VN services, and best effort VN services. In addition to
processing the DoS VN priority in the SVP bandwidth allocation setup, the VN
priority of service parameter also needs to be associated with the SVP. In
the case of SVCs, we recommend using the DIFFSERV parameter recommended in
[ATM990097] to accommodate the SVC priority of service parameters in the
setup signaling message. The DIFFSERV parameter will also provide the
per-hop-behavior (PHB) priority required by IP flows. From the DIFFSERV
priority of service parameter, the ATM node can determine the QoS treatment
based on the QoS resource management (priority queuing) rules for key VN
cells, normal VN cells, and best effort VN cells
A summary of example methods for SVP and SVC QoS resource management in ATM
networks, as recommended in [AM99], is as follows:
a) ONs monitor VN bandwidth use and decide when to make SVP bandwidth
modification requests. ONs apply DoS rules to determine the DoS threshold
to apply for a bandwidth modification request.
b) VNs keep track of link state and compare DoS threshold parameters to
link state (as do ONs).
c) ONs formulate the SVP modify request message with optional DoS
parameter specifying the allowed bandwidth allocation threshold and queuing
priority on each link in the SVP. Alternatively ONs specify the optional
DoS in the SETUP message.
d) VNs or DNs formulate the optional bandwidth-not-available parameter
in the SVP modify reject message, when a given SVP cannot accommodate a
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 43]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
bandwidth request, to allow the ON to search out the additional bandwidth on
additional SVPs.
ANNEX C - IP-BASED INTRANETWORK ROUTING/SWITCHING METHODS
In IP-based networks the open shortest route first (OSPF) standard [M98,
S95] for intra-domain routing, the border gateway protocol (BGP) [S95] for
inter-domain routing, and other routing protocols [S95], have been adopted
by the Internet Engineering Task Force (IETF). These protocols provide for
a) exchange of node and link status information, b) automatic update and
synchronization of topology databases, and c) fixed and/or dynamic route
selection based on topology and status information. Automatic update and
synchronization of topology database methods have been deployed over the
past two decades in IP-based networks, and this Recommendation suggests that
compatible topology database synchronization methods be extended to
TDM-based networks and to interworking between TDM-, ATM-, and IP-based
networks. For topology database synchronization, each node in an IP-based
OSPF/BGP network exchanges HELLO packets with its immediate neighbors and
thereby determines its local state information. This state information
includes the identity and group membership of the node's immediate
neighbors, and the status of its links to the neighbors. Each node then
bundles its state information in link state advertisements (LSAs), which are
reliably flooded throughout the autonomous system (AS), or group of nodes
exchanging routing information and using a common routing protocol, which is
analogous to the PNNI peer group used in ATM-based networks. The LSAs are
used to flood node information, link state information, and reachability
information. As in PNNI, some of the topology state information is static
and some is dynamic. In order to allow larger AS group sizes, a network can
use OSPF in such a way so as to minimize the amount of dynamic topology
state information flooding by setting thresholds to values that inhibit
frequent updates.
IP-based routing of connection/bandwidth-allocation requests and QoS support
are in the process of standardization primarily within the MPLS and
differentiated services (DIFFSERV) [B99, ST98] activities in the IETF. The
following assumptions are made regarding the outcomes of these IP-based
routing standardization efforts:
a) Call control in support of connection establishment functions
efficiently on a per-connection basis, and uses a protocol such as H.323
[H.323] and the session initiation protocol (SIP) [HSSR99]. It is assumed
that the call control signaling protocol interworks with the B-ISUP and PNNI
signaling protocols to accommodate setup and release of connection requests.
b) Connection/bandwidth-allocation control in support of route
selection is assumed to employ OSPF/BGP route selection methods in
combination with multiprotocol label switching (MPLS). MPLS employs a
constraint-based routing label distribution protocol (CRLDP) [AMAOM98,
CDFFSV97, J99] or a resource reservation protocol (RSVP) [BZBHJ97] to
establish constraint-based routing label switched paths (CRLSPs). Bandwidth
allocation to CRLSPs is managed in support of QoS resource management, as
discussed in Section C.3.
c) The CRLDP label request message (equivalent to the setup message)
carries the explicit route (equivalent to the DTL) parameter specifying the
via nodes (VNs) and destination node (DN) in the selected CRLSP and the DoS
parameter specifying the allowed bandwidth selection threshold on a link.
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 44]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
d) The CRLDP notify (equivalent to the release) message is assumed to
carry the crankback/bandwidth-not-available parameter specifying return of
control of the connection/bandwidth-allocation request to the originating
node (ON), for possible further alternate routing to establish additional
CRLSPs.
e) Call control signaling is coordinated with
connection/bandwidth-allocation control CRLDP/MPLS signaling and routing for
connection/bandwidth-allocation establishment.
f) Reachability information is exchanged between all nodes. To
provision a new IP address, the node serving that IP address is provisioned.
The reachability information is then flooded to all the nodes in the network
using the OSPF LSA flooding mechanism.
g) The ON performs destination address translation, screening, service
processing, and all steps necessary to determine the routing table for the
connection/bandwidth-allocation request across the IP network. The ON makes
a connection/bandwidth-allocation request admission if bandwidth is
available and places the connection/bandwidth-allocation request on a
selected CRLSP.
These assumption on IP-based routing standardization outcomes are discussed
in more detail in the following Sections.
C.1 IP-Based Number Translation/Routing
IP-based networks employ an IP addressing method to identify node endpoints
[S94]. A mechanism is needed to translate E.164 NSAPs to IP addresses in an
efficient manner. Proposals have been made [ETSIa, ETSIb, ETSIc, PL99] to
interwork between IP addressing and E.164 numbering/addressing, in which a
translation database is recommended, based on domain name server (DNS)
technology, to convert E.164 addresses to IP addresses. With such a
capability, IP nodes could make this translation of E.164 NSAPs directly,
and thereby provide interworking with TDM- and ATM-based networks which use
E.164 numbering and addressing. If this is the case, then E.164 NSAPs could
become a standard addressing method for interworking across TDM-, ATM-, and
IP-based networks.
C.2 IP-Based Routing Table Management & Route Selection
As stated above, route selection in an IP-based network is assumed to employ
OSPF/BGP in combination with MPLS and the CRLDP protocol that functions
efficiently in combination with call control establishment of individual
connections. In OSPF-based layer 3 routing, similar to the example shown in
ANNEX B Figure B1, an ON S1 determines a list of shortest routes by using,
for example, Dijsktra's algorithm. This route list could be determined
based on administrative weights of each link, which are communicated to all
nodes within the AS group. These administrative weights may be set, for
example, to 1 + epsilon x distance, where epsilon is a factor giving a
relatively smaller weight to the distance in comparison to the hop count.
The ON selects a route from the list based on, for example, FR, TDR, SDR, or
EDR route selection, as described in ANNEX A.2. For example, to establish a
CRLSP on the first route, the ON S1 sends an CRLDP label request message to
VN S2, which in turn forwards the CRLDP label request message to VN S3, and
finally to DN S4. The VNs S2 and S3 and DN S4 are passed in the explicit
route (ER) parameter contained in the CRLDP label request message. Each
node in the route reads the ER information, and passes the CRLDP label
request message to the next node listed in the ER parameter. If the first
route is blocked at any of the links in the route, a CRLDP notify message
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 45]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
with crankback/bandwidth-not-available parameter is returned to the ON which
can then attempt the next route. If FR is used, then this route is the next
route in the shortest route list, for example route S1-S6-S7-S8-S4. If TDR
is used, then the next route is the next route in the routing table for the
current time period. If SDR is used, OSPF implements a distributed method
of flooding link status information, which is triggered either periodically
and/or by crossing load state threshold values. As described in the
beginning of this Section, this method of distributing link status
information can be resource intensive and indeed may not be any more
efficient than simpler route selection methods such as EDR. If EDR is used,
then the next route is the last successful route, and if that route is
unsuccessful another alternate route is searched out according to the EDR
route selection method.
C.3 IP-Based QoS Resource Management
The methods described in ANNEX A.3 and B.3 are recommended to be extended to
IP-based networks in [AAJL99], in order to interwork with TDM- and ATM-based
networks. As in the QoS resource management method discussed in Section 6.4
and B.3, the DoS parameter is carried in the CRLDP label request message, so
that each VN can compare the load state on the link to the allowed DoS
threshold to determine if the connection/bandwidth-allocation request is
admitted or blocked on that link. In the IP-based network, the CRLDP label
request message would need to carry the allowed DoS parameter as well.
QoS resource management methods have been applied successfully in PSTNs over
the past decade [A98], have been studied for extension to IP-based networks
[ACFM99], and are recommended in [AAJL99] for QoS resource management in
IP/MPLS-based networks [RCV99]. In the recommended QoS resource management
method, bandwidth is allocated in discrete changes to each of three virtual
networks (VNs) corresponding to high-priority key services, normal-priority
services, and best-effort low-priority services. Examples of services
within these VN categories include a) high-priority key priority services
such as defense voice communication, b) normal-priority services such as
constant rate, interactive, delay-sensitive voice; variable rate,
interactive, delay-sensitive IP-telephony; and variable rate,
non-interactive, non-delay-sensitive WWW file transfer, and c) low-priority
best effort services such as variable rate, non-interactive,
non-delay-sensitive voice mail, email, and file transfer. Bandwidth changes
in VN bandwidth capacity are determined by edge nodes based on an overall
aggregated bandwidth demand for VN capacity (not on a per-connection demand
basis). Based on the aggregated bandwidth demand, these edge nodes make
periodic discrete changes in bandwidth allocation, that is, either increase
or decrease bandwidth on the constraint-based routing label switched paths
(CRLSPs) constituting the VN bandwidth capacity.
[AAJL99] recommends that the bandwidth allocation control for each VN CRLSP
be based on estimated bandwidth needs, bandwidth use, and status of links in
the CRLSP. The edge node, or originating node (ON), determines when VN
bandwidth needs to be increased or decreased on a CRLSP, and uses a
recommended MPLS CRLSP bandwidth modification procedure to execute needed
bandwidth allocation changes on VN CRLSPs. In the bandwidth allocation
procedure CRLDP [J99] is used to specify appropriate parameters in the label
request message a) to request bandwidth allocation changes on each link in
the CRLSP, and b) to determine if link bandwidth can be allocated on each
link in the CRLSP. If a link bandwidth allocation is not allowed, a
recommended CRLDP notification message with
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 46]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
crankback/bandwidth-not-available parameter allows the ON to search out
possible bandwidth allocation on another CRLSP. In particular, [AAJL99]
recommends an optional DoS type/length/value (TLV) parameter in the CRLDP
label request message to control the bandwidth allocation on individual
links in a CRLSP. In addition, [AAJL99] recommends an optional modify-TLV
parameter in the CRLDP label request message to allow dynamic modification
of the assigned traffic parameters (such as peak data rate, committed data
rate, etc.) of an already existing CRLSP. Finally, [AAJL99] recommends a
crankback/bandwidth-not-available-TLV parameter in the CRLDP notification
message to allow an edge node to search out additional alternate CRLSPs when
a given CRLSP cannot accommodate a bandwidth request. [AAJL99] addresses
point-to-point QoS resource management; multipoint QoS resource management
is left for future study.
Through the use of bandwidth allocation, reservation, and congestion control
techniques, QoS resource management can provide good network performance
under normal and abnormal operating conditions for all services sharing the
integrated network [A98]. Such methods have been analyzed in recent
modeling studies for IP-based networks [ACFM99], and in this draft these
IP-based QoS resource management methods are described. However, the
intention here is to illustrate the general principles of QoS resource
management and not to recommend a specific implementation. In the
multi-service, QoS resource management network, bandwidth is allocated to
the three individual VNs (high-priority key services VN, normal-priority
services VN, and best-effort low-priority services VN). This allocated
bandwidth is protected as needed but otherwise shared. Each ON monitors VN
bandwidth use on each VN CRLSP, and determines when VN CRLSP bandwidth needs
to be increased or decreased. Bandwidth changes in VN bandwidth capacity are
determined by ONs based on an overall aggregated bandwidth demand for VN
capacity (not on a per-connection demand basis). Based on the aggregated
bandwidth demand, these ONs make periodic discrete changes in bandwidth
allocation, that is, either increase or decrease bandwidth on the CRLSPs
constituting the VN bandwidth capacity. For example, if connection requests
are made for VN CRLSP bandwidth that exceeds the current CRLSP bandwidth
allocation, the ON initiates a bandwidth modification request on the
appropriate CRLSP(s). For example, this bandwidth modification request may
entail increasing the current CRLSP bandwidth allocation by a discrete
increment of bandwidth denoted here as delta-bandwidth (DBW). DBW is a
large enough bandwidth change so that modification requests are made
relatively infrequently. Also, the ON periodically monitors CRLSP bandwidth
use, such as once each minute, and if bandwidth use falls below the current
CRLSP allocation the ON initiates a bandwidth modification request to
decrease the CRLSP bandwidth allocation by a unit of bandwidth such as DBW.
In making a VN bandwidth allocation modification, the ON determines the QoS
resource management parameters including the VN priority (key, normal, or
best-effort), VN bandwidth-in-use, VN bandwidth allocation thresholds, and
whether the CRLSP is a first choice CRLSP or alternate CRLSP. These
parameters are used to access a VN depth-of-search (DoS) table to determine
a DoS load state threshold, or the "depth" to which network capacity can be
allocated for the VN bandwidth modification request. In using the DoS
threshold to allocate VN bandwidth capacity, the ON selects a first choice
CRLSP based on the routing table selection rules. Route selection in the IP
network may use open shortest route first (OSPF) [M98, S95] for intra-domain
routing. In OSPF-based layer 3 routing, as illustrated in Figure2, ON A
determines a list of shortest routes by using, for example, Dijkstra's
algorithm. This route list could be determined based on administrative
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 47]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
weights of each link, which are communicated to all nodes within the
autonomous system (AS) domain. These administrative weights may be set, for
example, to [1 + epsilon x distance], where epsilon is a factor giving a
relatively smaller weight to the distance in comparison to the hop count.
The ON selects a route from the list based on, for example, fixed routing
(FR), time dependent routing (TDR), state dependent routing (SDR), or event
dependent routing (EDR) route selection [A98].
For example, in using the first CRLSP A-B-E in Figure 2, ON A sends CRLDP
label request message to via node (VN) B, which in turn forwards the CRLDP
label request message to destination node (DN) E. VN B and DN E are passed
in the explicit routing CR/TLV parameter contained in the CRLDP label
request message. Each node in the CRLSP reads the CR/TLV information, and
passes the CRLDP label request message to the next node listed in the CRLSP.
If the first route is blocked at any of the links in the route, a CRLDP
notification message with a recommended constraint-based routing
type/length/value (CR/TLV) crankback/bandwidth-not-available parameter is
returned to ON A which can then attempt the next route. If FR is used, then
this route is the next route in the shortest route list, for example route
A-C-D-E. If TDR is used, then the next route is the next route in the
routing table for the current time period. If SDR is used, OSPF implements
a distributed method of flooding link status information, which is triggered
either periodically and/or by crossing load state threshold values. This
method of distributing link status information can be resource intensive and
may not be any more efficient than simpler route selection methods such as
EDR. If EDR is used, then the next route is the last successful route, and
if that route is unsuccessful another alternate route is searched out
according to the EDR route selection method.
Hence in using the selected CRLSP, the ON sends the explicit route, the
requested traffic parameters (peak data rate, committed data rate, etc.), an
optional DoS-TLV parameter, and an optional modify-TLV parameter in the
CRLDP label request message to each VN and the DN in the selected CRLSP.
Whether or not bandwidth can be allocated to the bandwidth modification
request on the first choice CRLSP is determined by each VN applying the QoS
resource management rules. These rules entail that the VN determine the
CRLSP link states (lightly loaded, heavily loaded, reserved, or busy), based
on bandwidth use and bandwidth available, and compare the link load state to
the DoS threshold sent in the CRLDP TLV parameters, as further explained
below. If the first choice CRLSP cannot be accessed, a VN or DN returns
control to the ON through the use of a recommended
crankback/bandwidth-not-available-TLV parameter in the CRLDP notification
message. At that point the ON may then try an alternate CRLSP. Whether or
not bandwidth can be allocated to the bandwidth modification request on the
alternate route again is determined by the use of the DoS threshold compared
to the CRLSP link load state at each VN. Priority queuing is used during
the time the connection is established, and at each link the queuing
discipline is maintained such that the packets are given priority according
to the VN traffic priority.
In the recommended method of QoS resource management, the admission control
for bandwidth modification on each VN CRLSP is based on the status of the
links in the CRLSP. The ON may select any CRLSP for which the first CRLSP
link is allowed according to QoS resource management criteria. If a
subsequent CRLSP link is not allowed, then a recommended CRLDP notification
message with a crankback/bandwidth-not-available-TLV parameter is used to
return to the ON and select an alternate CRLSP. Determination of the CRLSP
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 48]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
link load states is necessary for QoS resource management to select network
capacity on either the first choice CRLSP or alternate CRLSPs. Four link
load states are distinguished: lightly loaded (LL), heavily loaded (HL),
reserved (R), and busy (B). Management of CRLSP capacity uses a link state
model and a depth-of-search (DoS) model to determine if a bandwidth
modification request can be accepted on a given CRLSP. The allowed DoS load
state threshold determines if a bandwidth modification request can be
accepted on a given link to an available bandwidth "depth." In setting up
the bandwidth modification request, the ON encodes the DoS load state
threshold allowed on each link in the recommended DoS-TLV parameter in the
CRLDP label request. If a CRLSP link is encountered at a VN in which the
idle link bandwidth and link load state are below the allowed DoS load state
threshold, then the VN sends a CRLDP notification message with a recommended
crankback/bandwidth-not-available-TLV parameter to the ON, which can then
route the bandwidth modification request to an alternate CRLSP choice. For
example, in Figure2, CRLSP A-B-E may be the first route tried where link A-B
is in the LL state and link B-E is in the R state. If the DoS load state
allowed is HL or better, then the CRLSP bandwidth modification request in
the CRLDP label request message is routed on link A-B but will not be
admitted on link B-E, wherein the CRLSP bandwidth modification request will
be cranked back in the CRLDP notification message to the originating node A
to try alternate CRLSP A-C-D-E. Here the CRLSP bandwidth modification
request succeeds since all links have a state of HL or better.
The DoS load state threshold is a function of bandwidth-in-progress, VN
priority, and bandwidth allocation thresholds [ACFM99], as follows:
Table C1
Determination of Depth-of-Search (DoS) Load State Threshold
------------------------------------------------------------------------------
Load State Key Normal Priority VN Best Effort
Allowed Priority VN ---------------------------------- Priority VN
First Choice CRLSP Alternate CRLSP
------------------------------------------------------------------------------
R if BWIPi <= if BWIPi <= BWavgi Not Allowed Note 1
2 * BWmaxi
HL if BWIPi <= if BWIPi <= BWmaxi if BWIPi <= Note 1
2 * BWmaxi BWavgi
LL All BWIPi All BWIPi All BWIPi Note 1
where
BWIPi = bandwidth-in-progress on VN i
BWavgi = minimum guaranteed bandwidth required for VN
i to carry the
average offered bandwidth load
BWmaxi = the bandwidth required for VN i to meet the
blocking probability grade-of-service
objective for CRLSP bandwidth allocation
requests
= 1.1 x BWavgi
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 49]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
Note 1 = CRLSPs for the best effort priority VN are
allocated zero bandwidth;
Diffserv queuing admits best effort packets
only if there is available bandwidth on a
link
Note that BWIP, BWavg, and BWmax are specified per ON-DN pair, and that the
QoS resource management method provides for a key priority VN, a normal
priority VN, and a best effort VN. Key services admitted by an ON on the
key VN are given higher priority routing treatment by allowing greater route
selection DoS than normal services admitted on the normal VN. Best effort
services admitted on the best effort VN are given lower priority routing
treatment by allowing lesser route selection DoS than normal. The
quantities BWavgi are computed periodically, such as every week w, and can
be exponentially averaged over a several week period, as follows:
BWavgi(w) = .5 x BWavgi(w-1) + .5 x [ BWIPavgi(w) +
BWOVavgi(w) ]
BWIPavgi = average bandwidth-in-progress across a load
set period on VN i
BWOVavgi = average bandwidth allocation request
rejected (or overflow) across a load
set period on VN i
where all variables are specified per ON-DN pair, and where BWIPi and BWOVi
are averaged across various load set periods, such as morning, afternoon,
and evening averages for weekday, Saturday, and Sunday, to obtain BWIPavgi
and BWOVavgi.
Illustrative values of the thresholds to determine link load states are as
follows [ACFM99]:
Table C2
Determination of Link Load State
-----------------------------------------------
Name of State Condition
-----------------------------------------------
Busy (B) ILBWk < DBW
Reserved (R) ILBWk * Rthrk
Heavily Loaded (HL) Rthrk < ILBWk * HLthrk
Lightly Loaded (LL) HLthrk < ILBWk
where
ILBWk = idle link bandwidth on link k
DBW = delta bandwidth requirement for a bandwidth
allocation
request
Rthrk = reservation bandwidth threshold for link k
= N x .05 x TBWk for bandwidth reservation
level N
HLthrk = heavily loaded bandwidth threshold for link
k
= Rthrk + .05 x TBWk
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 50]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
TBWk = the total bandwidth required on link k to
meet the blocking probability
grade-of-service
objective for bandwidth allocation requests
on
their first choice CRLSP.
QoS resource management implements bandwidth reservation logic to favor
connections routed on the first choice CRLSP in situations of link
congestion. If link congestion (or blocking) is detected, bandwidth
reservation is immediately triggered and the reservation level N is set for
the link according to the level of link congestion. In this manner
bandwidth allocation requests attempting to alternate-route over a congested
link are subject to bandwidth reservation, and the first choice CRLSP
requests are favored for that link. At the same time, the LL and HL link
state thresholds are raised accordingly in order to accommodate the reserved
bandwidth capacity N for the VN. Figure A3 illustrates bandwidth allocation
and the mechanisms by which bandwidth is protected through bandwidth
reservation. Under normal bandwidth allocation demands bandwidth is fully
shared, but under overloaded bandwidth allocation demands, bandwidth is
protected through the reservation mechanisms wherein each VN can use its
allocated bandwidth. Under failure, however, the reservation mechanisms
operate to give the key VN its allocated bandwidth before the normal
priority VN gets its bandwidth allocation. As noted on Table C1, the best
effort low-priority VN is not allocated bandwidth nor is bandwidth reserved
for the best effort VN. Illustrations are given in [A98] of the robustness
of dynamic bandwidth reservation in protecting the preferred bandwidth
requests across wide variations in traffic conditions.
The reservation level N (for example, N may have 1 of 4 levels), is
calculated for each link k based on the link blocking level of bandwidth
allocation requests. The link blocking level is equal to the total
requested but rejected (or overflow) link bandwidth allocation (measured in
total bandwidth), divided by the total requested link bandwidth allocation,
over the last periodic update interval, which is, for example, every three
minutes. That is
BWOVk = total requested bandwidth allocation
rejected (or overflow) on
link k
BWOFk = total requested or offered bandwidth
allocation on link k
LBLk = link blocking level on link k
= BWOVk/BWOFk
If LBLk exceeds a threshold value, the reservation level N is calculated
accordingly. The reserved bandwidth and link states are calculated based on
the total link bandwidth required on link k, TBWk, which is computed
on-line, for example every 1-minute interval m, and approximated as follows:
TBWk(m) = .5 x TBWk(m-1) +
.5 x [ 1.1 x TBWIPk(m) +
TBWOVk(m)]
TBWIPk = sum of the bandwidth in progress
(BWIPi) for all VNs i for bandwidth
requests on their first choice CRLSP
over link k
TBWOVk = sum of bandwidth overflow (BWOVi)
for
all VNs i for bandwidth requests on
their first choice CRLSP over link k
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 51]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
Therefore the reservation level and load state boundary thresholds are
proportional to the estimated required bandwidth load, which means that the
bandwidth reserved and the bandwidth required to constitute a lightly loaded
link rise and fall with the bandwidth load, as, intuitively, they should.
In addition to the QoS bandwidth management procedure for bandwidth
allocation requests, a QoS priority of service queuing capability is used
during the time connections are established on each of the three VNs. At
each link, a queuing discipline is maintained such that the packets being
served are given priority in the following order: key VN services, normal VN
services, and best effort VN services. Following the MPLS CRLSP bandwidth
allocation setup and the application of QoS resource management rules, the
priority of service parameter and label parameter need to be sent in each IP
packet, as illustrated in Figure C1.
<>
The priority of service parameter may be included in the type of service
(ToS), or differentiated services (DIFFSERV) [B98, ST98], parameter already
in the IP packet header. Another possible alternative is that the priority
of service parameter might be included in the MPLS label or "shim" appended
to the IP packet (this is a matter for further study). In either case, from
the priority of service parameter, the IP node can determine the QoS
treatment based on the QoS resource management (priority queuing) rules for
key VN packets, normal VN packets, and best effort VN packets. From the
label parameter, the IP node can determine the next node to route the IP
packet to as defined by the MPLS protocol. In this way, the backbone nodes
can have a very simple per-packet processing implementation to implement QoS
resource management and MPLS routing.
In summary [AAJL99, AAFJLLS99] give these example methods regarding CRLDP
use in MPLS:
a) Edge nodes, or ONs, monitor VN bandwidth use and decide when to make
CRLSP bandwidth modification requests. ONs keep track of VN priority,
bandwidth-in-use, and bandwidth allocation thresholds and apply DoS rules to
determine the DoS threshold to apply for a bandwidth modification request.
b) Backbone nodes, or VNs, keep track of link state and compare DoS
threshold parameters to link state (as do ONs).
c) ONs formulate the CRLDP label request message, which carries the
explicit routing parameters specifying the VNs and DN in the selected CRLSP,
the optional DoS-TLV parameter specifying the allowed bandwidth allocation
threshold on each link in the CRLSP, and the optional modify-TLV parameter
to allow modification of the assigned traffic parameters (such as peak data
rate, committed data rate, etc.) of an already existing CRLSP.
d) VNs or DNs formulate the optional
crankback/bandwidth-not-available-TLV parameter in the CRLDP notification
message, which specifies return of control of the link bandwidth allocation
request to the ON, for possible further alternate routing to search out
additional alternate CRLSPs when a given CRLSP cannot accommodate a
bandwidth request.
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 52]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
ANNEX D - BIBLIOGRAPHY
[A98] Ash, G. R., Dynamic Routing in Telecommunications Networks,
McGraw-Hill, 1998.
[AAFJLLS99] Ash, G. R., Ashwood-Smith, P., Fedyk, D., Jamoussi, B., Lee,
Y., Li, L., Skalecki, D., LSP Modification Using CRLDP,
draft-ash-crlsp-modify-00.txt, July 1999.
[ACFM99] Ash, G. R., Chen, J., Fishman, S. D., Maunder, A., Routing
Evolution in Multiservice Integrated Voice/Data Networks, International
Teletraffic Congress ITC-16, Edinburgh, Scotland, June 1999.
[ADFFT98] Anderson, L., Doolan, P., Feldman, N., Fredette, A., Thomas, B.,
LDP Specification, IETF Draft, draft-ietf-mpls-ldp-01.txt, August 1998.
[AL99] Ash, G. R., Lee, Y., Routing of Multimedia Connections Across TDM-,
ATM-, and IP-Based Networks, IETF Draft,
draft-ash-itu-sg2-qos-routing-00.txt, May 1999.
[AM98] Ash, G. R., Maunder, A., Routing of Multimedia Connections when
Interworking with PSTN, ATM, and IP Networks, AF-98-0927, Nashville TN,
December 1998.
[AAJL99] Ash, G. R., Aboul-Magd, O. S., Jamoussi, B., Lee, Y., QoS Resource
Management in MPLS-Based Networks, IETF Draft, draft-ash-qos-routing-00.txt,
Minneapolis MN, March 1999.
[AM99] Ash, G. R., Maunder, A., QoS Resource Management in ATM Networks,
AF-99-, Rome Italy, April 1999.
[AMAOM98] Awduche, D. O., Malcolm, J. Agogbua, J., O'Dell, M., McManus, J.,
Requirements for Traffic Engineering Over MPLS, IETF Draft,
draft-ietf-mpls-traffic-eng-00.txt, October 1998.
[ATM95] ATM Forum Technical Committee, B-ISDN Inter Carrier Interface
(B-ICI) Specification Version 2.0 (Integrated), af-bici-0013.003, December
1995.
[ATM960055] ATM Forum Technical Committee, Private Network-Network
Interface Specification Version 1.0 (PNNI 1.0), af-pnni-0055.000, March
1996.
[ATM960056] ATM Forum Technical Committee, Traffic Management Specification
Version 4.0, af-tm0056.000, April 1996.
[ATM960061] ATM Forum Technical Committee, ATM User-Network Interface (UNI)
Signaling Specification Version 4.0, af-sig-0061.000, July 1996.
[ATM98] ATM Forum Technical Committee, Specification of the ATM
Inter-Network Interface (AINI) (Draft), ATM Forum/BTD-CS-AINI-01.03, July
1998.
[ATM990097] ATM Signaling Requirements for IP Differentiated Services and
IEEE 802.1D, ATM Forum, Atlanta, GA, February 1999.
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 53]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
[B99] Bernet, Y., et. al., A Framework for Differentiated Services, IETF
draft-ietf-diffserv-framework-02.txt, February 1999.
[BZBHJ97] Bradem. R., Zhang, L., Berson, S., Herzog, S., Jamin, S.,
Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification,
IETF Network Working Group RFC 2205, September 1997.
[CDFFSV97] Callon, R., Doolan, P., Feldman, N., Fredette, A., Swallow, G.,
Viswanathan, A., IETF Network Working Group Draft, A Framework for
Multiprotocol Label Switching, draft-ietf-mpls-framework-02.txt, November
1997.
[CNRS98] Crawley, E., Nair, R., Rajagopalan, B., Sandick, H., A Framework
for QoS-based Routing in the Internet, IETF RFC 2386, August 1998.
[COM 2-39-E] ANNEX, Draft New Recommendation E.ip, Report of Joint Meeting
of Questions 1/2 and 10/2, Torino, Italy, July 1998.
[D99] Dvorak, C., IP-Related Impacts on End-to-End Transmission
Performance, ITU-T Liaison to Study Group 2, Temporary Document TD GEN-22,
Geneva Switzerland, May 1999.
[DN99] Dianda, R. B., Noorchashm, M., Bandwidth Modification for UNI, PNNI,
AINI, and BICI, ATM Forum Technical Working Group, April 1999.
[ETSIa] ETSI Secretariat, Telecommunications and Internet Protocol
Harmonization over Networks (TIPHON); Naming and Addressing; Scenario 2,
DTS/TIPHON-04002 v1.1.64, 1998
[ETSIb] ETSI STF, Request for Information (RFI): Requirements for Very
Large Scale E.164 -> IP Database, TD35, ETSI EP TIPHON 9, Portland,
September 1998.
[ETSIc] TD290, ETSI Working Party Numbering and Routing, Proposal to Study
IP Numbering, Addressing, and Routing Issues, Sophia, September 1998.
[G99a] Glossbrenner, K., Elements Relevant to Routing of ATM Connections,
ITU-T Liaison to Study Group 2, Temporary Document 1/2-8, Geneva
Switzerland, May 1999.
[G99b] Glossbrenner, K., IP Performance Studies, ITU-T Liaison to Study
Group 2, Temporary Document GEN-27, Geneva Switzerland, May 1999.
[GWA97] Gray, E., Wang, Z., Armitage, G., Generic Label Distribution
Protocol Specification, IETF Draft, draft-gray-mpls-generic-ldp-spec-00.txt,
November 1997.
[GR99] Greene, N., Ramalho, M., Media Gateway Control Protocol Architecture
and Requirements, IETF Draft, draft-ietf-megaco-reqs-00.txt, January 1999.
[HSSR99] Handley, M., Schulzrinne, H., Schooler, E. Rosenberg, J. SIP:
Session Initiation Protocol, IETF RFC 2543, March 1999.
[J99] Jamoussi, B., Editor, Constraint-Based LSP Setup using LDP, IETF
draft-ietf-mpls-cr-ldp-01.txt, February 1999.
[LKPCD98] Luciani, J., Katz, D., Piscitello, D., Cole, B., Doraswamy, N.,
NBMA Next Hop Resolution Protocol (NHRP), IETF RFC 2332, April 1998.
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 54]
Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks Oct 99
[M98] Moy, J, OSPF Version 2, IETF RFC 2328, April 1998.
[PARLAY] Parlay API Specification 1.2, September 10, 1999.
[PL99] Faltstrom, P., Larson, B., E.164 Number and DNS, IETF
draft-faltstrom-e164-03.txt, September 1999.
[RVC99] Rosen, E., Viswanathan, A., Callon, R., Multiprotocol Label
Switching Architecture, IETF draft-ietf-mpls-arch-04.txt, February 1999.
[S94] Stevens, W. R., TCP/IP Illustrated, Volume 1, The Protocols,
Addison-Wesley, 1994.
[S95] Steenstrup, M., Editor, Routing in Communications Networks,
Prentice-Hall, 1995.
[SCFJ96] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V., RTP: A
Transport Protocol for Real-Time Applications, IETF RFC 1889, January 1996.
[ST98] Sikora, J., Teitelbaum, B., Differentiated Services for Internet2,
Internet2: Joint Applications/Engineering QoS Workshop, Santa Clara, CA, May
1998.
[T1S198] ATM Trunking for the PSTN/ISDN, Committee T1S1.3 (B-ISUP),
T1S1.3/98, NJ, December 1998.
[ZSSC97] Zhang, Sanchez, Salkewicz, Crawley, Quality of Service Extensions
to OSPF or Quality of Service Route First Routing (QOSPF), IETF Draft,
draft-shang-qos-ospf-01.txt, September 1997.
Ash, Lee <draft-ash-itu-sg2-qos-routing-02.txt> [Page 55]