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]