Internet Draft
Internet Draft                                          Gerald R. Ash
                                                        Young Lee
                                                        AT&T

                                                        May 1999

Expires: November 1999

                Routing of Multimedia Connections Across
                   TDM-, ATM-, and IP-Based Networks

                <draft-ash-itu-sg2-qos-routing-01.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
Draft Recommendation  E.MM "Routing of Multimedia Connections Across TDM-,
ATM-,  and IP-based Networks."  In our May 1999 meeting in Geneva, we
discussed the current draft text and this contribution presents a proposed
updated text of Recommendation E.MM based on the comments and input.  It is
intended that the Draft Recommendation will be presented to the ATM Forum
and IETF for their comment and discussion.

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.

More specifically, this Recommendation addresses the number
translation/routing, routing table management, route selection, and

Ash, Lee                      [Page 1]

Internet Draft  Routing Across TDM-, ATM-, & IP-Based Networks    May 99

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.  In addition, this
Recommendation identifies the signaling and information-exchange
requirements needed to support these routing methods.  These include a) the
topology update information exchange applied in ATM- and IP-based networks,
b) the routing table design information exchange applied in TDM-based
networks, and c) the route selection information exchange applied in
ATM-based networks.  The latter includes originating-node-controlled
(source) routing, specification of via and destination nodes in a parameter
in a setup message, and return of control to the originating node with a
crankback/bandwidth-not-available parameter in the release message.

***************************************************************************
NOTE: A MICROSOFT WORD VERSION OF THIS DRAFT (WITH THE FIGURES) IS
       AVAILABLE ON REQUEST
***************************************************************************

Ash, Lee                      [Page 2]

Internet Draft  Routing Across TDM-, ATM-, & IP-Based Networks    May 99

                          Table of Contents
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.0 Scope  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.0 Definitions  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.0 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.0 Abbreviations  . . . . . . . . . . . . . . . . . . . . . . . .  11
6.0 Recommended Routing Methods  . . . . . . . . . . . . . . . . .  13
6.1 Number Translation/Routing . . . . . . . . . . . . . . . . . .  15
6.2 Routing Table Management . . . . . . . . . . . . . . . . . . .  15
6.2.1 Topology Update  . . . . . . . . . . . . . . . . . . . . . .  16
6.2.2 Status Update  . . . . . . . . . . . . . . . . . . . . . . .  16
6.2.3 Query for Status . . . . . . . . . . . . . . . . . . . . . .  16
6.2.4 Routing Recommendation . . . . . . . . . . . . . . . . . . .  16
6.3 Route Selection  . . . . . . . . . . . . . . . . . . . . . . .  16
6.4 QoS Resource Management  . . . . . . . . . . . . . . . . . . .  17
6.4.1 QoS Resource Management Steps. . . . . . . . . . . . . . . .  18
6.4.2 Bandwidth-Allocation, Bandwidth-Protection, and Priority-
      Routing Issues . . . . . . . . . . . . . . . . . . . . . . .  19
6.4.3 Other QoS Routing Constraints. . . . . . . . . . . . . . . .  22
6.4.4 Priority Queuing. . . . . . .. . . . . . . . . . . . . . . .  23
6.5 Harmonization of Routing Methods Standards . . . . . . . . . .  23
7.0 Signaling and Information Exchange Requirements. . . . . . . .  24
7.1 Routing Table Management Information-Exchange Parameter. . . .  26
7.2 Route Selection Information-Exchange Parameters. . . . . . . .  27
7.3 QoS Resource Management Information-Exchange Parameters. . . .  28
7.4 Harmonization of Information-Exchange Standards. . . . . . . .  28
8.0 Examples of Internetwork Routing . . . . . . . . . . . . . . .  29
8.1 Internetwork E Uses a Mixed Route Selection Methods. . . . . .  29
8.2 Internetwork E Uses a Single Route Selection Methods . . . . .  31
9.0 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  31
ANNEX A TDM-Based Intranetwork Routing Methods . . . . . . . . . .  32
A.1 TDM-Based Number Translation/Routing . . . . . . . . . . . . .  32
A.2 TDM-Based Routing Table Management & Route Selection . . . . .  32
A.2.1 Fixed Routing (FR) . . . . . . . . . . . . . . . . . . . . .  33
A.2.2 Time-Dependent Routing (TDR) . . . . . . . . . . . . . . . .  33
A.2.3 State-Dependent Routing (SDR). . . . . . . . . . . . . . . .  34
A.2.4 Event-Dependent Routing (EDR). . . . . . . . . . . . . . . .  35
A.3 TDM-Based QoS Resource Management  . . . . . . . . . . . . . .  36
A.4 TDM-Based Signaling and Information Exchange . . . . . . . . .  36
A.4.1 Connection/Bandwidth-Allocation Control Information. . . . .  36
A.4.2 Routing Table Management Information . . . . . . . . . . . .  37
A.4.3 Examples of Information Exchange . . . . . . . . . . . . . .  37
ANNEX B ATM-Based Intranetwork Routing Methods . . . . . . . . . .  39
B.1 ATM-Based Number Translation/Routing . . . . . . . . . . . . .  40
B.2 ATM-Based Routing Table Management & Route Selection . . . . .  40
B.3 ATM-Based QoS Resource Management  . . . . . . . . . . . . . .  41
B.4 ATM-Based Signaling and Information Exchange . . . . . . . . .  44
B.4.1 Connection/Bandwidth-Allocation Control Information. . . . .  44
B.4.2 Routing Table Management Information . . . . . . . . . . . .  45
B.4.3 Topology Update Information. . . . . . . . . . . . . . . . .  45
ANNEX C IP-Based Intranetwork Routing Methods  . . . . . . . . . .  46
C.1 IP-Based Number Translation/Routing .. . . . . . . . . . . . .  47
C.2 IP-Based Routing Table Management & Route Selection  . . . . .  47
C.3 IP-Based QoS Resource Management   . . . . . . . . . . . . . .  48
C.4 IP-Based Signaling and Information Exchange  . . . . . . . . .  50
C.4.1 Connection/Bandwidth-Allocation Control Information. . . . .  55
C.4.2 Routing Table Management Information . . . . . . . . . . . .  55
C.4.3 Topology Update Information. . . . . . . . . . . . . . . . .  55

Ash, Lee                      [Page 3]

Internet Draft  Routing Across TDM-, ATM-, & IP-Based Networks    May 99

               E.MM - ROUTING OF MULTIMEDIA CONNECTIONS ACROSS
                      TDM-, ATM-, AND IP-BASED NETWORKS

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; it deals
with both routing methods and the  information exchange protocols to support
such methods.  The treatment of routing methods includes considerations of
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.

Various routing protocols are used in TDM-, ATM-, and IP-based networks.  In
TDM-based networks, for example, Recommendation E.DYN 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
o       exchange of node and link status information,
o       automatic update and synchronization of topology databases,
o       fixed and/or dynamic route selection based on topology and status
        information, and
o       signaling and information exchange standards.

In IP-based networks, for example, the open shortest route first (OSPF) and
other standards adopted by the Internet Engineering Task Force [M98, S95]
provide for many of the same features as PNNI, but in a connectionless
IP-based packet network.  OSPF provides for
o       exchange of node and link status information,
o       automatic update and synchronization of topology databases, and
o       fixed and/or dynamic route selection based on topology and status
        information.
This Recommendation addresses the interworking of these and other routing
methods, including information exchange at the interface across these
network types, for all services including multimedia services.  This
Recommendation addresses only point-to-point connections; multipoint
connections are left for future work.

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

Ash, Lee                      [Page 4]

Internet Draft  Routing Across TDM-, ATM-, & IP-Based Networks    May 99

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

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.
In addition, this Recommendation identifies the signaling and
information-exchange requirements needed to support these routing methods.
These include a) the topology update information exchange applied in ATM-
and IP-based networks, b) the routing table design information exchange
applied in TDM-based networks, and c) the route selection information
exchange applied in ATM-based networks.  The latter includes
originating-node-controlled (source) routing, specification of via and
destination nodes in a parameter in a setup message, and return of control
to the originating node with a crankback/bandwidth-not-available parameter
in the release message.

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.

Ash, Lee                      [Page 5]

Internet Draft  Routing Across TDM-, ATM-, & IP-Based Networks    May 99

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 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
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 Ash, Lee [Page 6] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 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. 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; 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: a via node within a given dynamic routing network; 4.0 References [A98] Ash, G. R., Dynamic Routing in Telecommunications Networks, McGraw-Hill, 1998. [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. Ash, Lee [Page 7] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 [AL98] Ash, G. R., Lee, Y., Routing of Multimedia Connections when Interworking with PSTN, ATM, and IP Networks, IETF Draft, draft-ash-itu-sg2-qos-routing-00.txt, Orlando, FL, December 1998. [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. [ADEHP98] Arango, M., Dugan, A., Elliott, I., Huitema, C., Pickett, S., Media Gateway Control Protocol (MGCP), Version 0.1 draft, IETF Draft, draft-huitema-MGCP-v0r1-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. [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. Ash, Lee [Page 8] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 [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. [E.DYN] ITU-T Draft Recommendation, Dynamic Routing Interworking. [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.412] ITU-T Recommendation, Network Management Controls. [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] TCR98, Taylor, P. T., Calhoun, P. R., Rubens, A. C., IPDC Base Protocol, IETF Draft, draft-taylor-ipdc-00.txt, July 1998. [ETSId] TD290, ETSI Working Party Numbering and Routing, Proposal to Study IP Numbering, Addressing, and Routing Issues, Sophia, September 1998. [ETSIe] TD27, TIPHON 10 Draft, H.323 Annex E: Call Signaling over UDP, Tel-Aviv, Israel, October 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. Ash, Lee [Page 9] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 [GR99] Greene, N., Ramalho, M., Media Gateway Control Protocol Architecture and Requirements, IETF Draft, draft-ietf-megaco-reqs-00.txt, January 1999. [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. [HSSR99] Handley, M., Schulzrinne, H., Schooler, E. Rosenberg, J. SIP: Session Initiation Protocol, IETF RFC 2543, March 1999. [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. [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. [LR98] Li, T., Rekhter, Y., A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE), IETF RFC 2430, October 1998. [M98] Moy, J, OSPF Version 2, IETF RFC 2328, April 1998. [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. [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. Ash, Lee [Page 10] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 [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. [TC98] Taylor, T. P., Calhoun, P. R., IPDC Base Protocol, IETF Draft, draft-taylor-ipdc-00.txt, July 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. 5.0 Abbreviations AAR Automatic Alternate Routing ABR Available Bit Rate AESA ATM End System Address AFI Authority and Format Identifier ARR Automatic Rerouting AS Autonomous System ATM Asynchronous Transfer Mode B-ISDN Broadband Integrated Services Digital Network B Busy BGP Border Gateway Protocol BW Bandwidth BWIP Bandwidth in Progress BWOF Bandwidth Offered BWOV Bandwidth Overflow BWPC Bandwidth Peg Count CAC Call Admission Control CBR Constant Bit Rate CCS Common Channel Signaling CRLDP Constraint-Based Routing Label Distribution Protocol CRLSP Constraint-Based Routing Label Switched Route DADR Distributed Adaptive Dynamic Routing DAR Dynamic Alternate Routing DCC Data Country Code DCR Dynamically Controlled Routing DIFFSERV Differentiated Services DoS Depth-of-Search DSP Domain Specific Part DTL Designated Transit List DN Destination Node DNHR Dynamic Nonhierarchical Routing EDR Event Dependent Routing ER Explicit Route FR Fixed Routing GCAC Generic Call Admission Control GOS Grade of Service Ash, Lee [Page 11] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 HL Heavily Loaded IAM Initial Address Message ICD International Code Designator IDI Initial Domain Identifier IETF Internet Engineering Task Force II Information Interchange ILBW Idle Link Bandwidth IP Internet Protocol IPDC Internet Protocol Device Control LBL Link Blocking Level LC Link capability LDP Label Distribution Protocol LL Lightly Loader LLR Least Loaded Routing LSA Link State Advertisement LSP Label Switched Route 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 OS Originating Node OSPF Open Shortest Route First ON Originating Node 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 RSVP Resource Reservation Protocol RTNR Real-Time Network Routing SCP Service Control Point SDR State-Dependent Routing SI Service Identity SIP Session Initiation Protocol STR State- and Time-Dependent Routing TBW Total Bandwidth TBWIP Total Bandwidth In Progress TDR Time-Dependent Routing TLV Type/Length/Value ToS Type of Service TIPHON Telecommunications and Internet Protocol Harmonization Over Networks TR Trunk Reservation UBR Unassigned Bit Rate VBR Variable Bit Rate VC Virtual Circuit VCI Virtual Circuit Identifier VN Virtual Network VPI Virtual Route Identifier VN Via Node WIN Worldwide Intelligent Network (Routing) Ash, Lee [Page 12] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 6.0 Recommended Routing Methods APPENDICES 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 APPENDICES 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 envisioned, 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 [Page 13] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 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 X X FFS X FFS Translation/ AESA FFS X FFS X Routing IP Address FFS FFS X FFS X -------------------------------------------------------------------- Routing Topology Update FFS X X X FFS Table Status Update E.DYN X X X X Management Query for E.DYN FFS FFS FFS FFS Status Routing Recom. E.DYN FFS FFS FFS FFS -------------------------------------------------------------------- Route Fixed Routing X X X X X Selection Time Dep. Rtg. E.DYN FFS FFS FFS FFS State Dep. Rtg. E.DYN X Q-OSPF X Q-OSPF Event Dep. Rtg. E.DYN FFS FFS FFS FFS -------------------------------------------------------------------- QoS Resource BW Allocation FFS BW MPLS BW MPLS Management & Protection MODIFY MODIFY Priority Rtg. FFS BW MPLS BW MPLS Priority N/A DIFF- DIFF- MPLS DIFF- Queuing SERV SERV SERV MPLS MPLS -------------------------------------------------------------------- FFS = for further study X = the routing method is supported by existing standards within the network technology STANDARD NAME = denotes a standard currently in progress which, when complete, will support the routing method 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 items for further study (FFS). 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. 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 Ash, Lee [Page 14] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 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. APPENDICES 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. 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 further aspect of number translation/routing methods is the use of routing numbers in the connection /bandwidth-allocation setup to direct a connection to a particular destination node [E.callrouting]. These number translation/routing methods need to be extended to IP-based networks, and as discussed in ANNEX C.1, work is underway in the TIPHON effort [ETSIa, ETSIb, ETSIc, ETSId, ETSIe] to interwork between IP addressing and E.164 numbering/addressing. TIPHON is proposing a translation database based on domain name service (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. 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, Ash, Lee [Page 15] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 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. 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. 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.DYN], 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. 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.DYN] provides for the query for status methods in TDM-based networks, as described in ANNEX A.2. 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.DYN] provides for the routing recommendation methods in TDM-based networks, as described in ANNEX A.2. 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. OS controlled, or source, routing is Ash, Lee [Page 16] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 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 routes (SVPs) in ATM-based networks or constraint-based routing label switched routes (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 OS in order to return the connection/bandwidth-allocation request to the ON, which may then select an alternate route. 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 setup (IAM, SETUP, MODIFY REQUEST, and LABEL REQUEST) message and the crankback/bandwidth-not-available parameter in the release (RELEASE, MODIFY REJECT, and NOTIFY) message. The DTL or ER parameter specifies all VNs and destination node or destination node (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. 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 supported within B-ISDN including IP-telephony, compressed video, and other services . c) Non-real-time VBR services supported within B-ISDN including WWW file transfer, credit card check, and other services. Ash, Lee [Page 17] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 d) UBR services supported within B-ISDN 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 including service identity (SI), virtual network (VNET), and bandwidth allocation threshold parameters. The VNET routing table determines which network capacity can be selected for each connection request or bandwidth-allocation request. In using the VNET routing table to select network capacity, the ON selects a first choice route based on the route selection rules, and sends a route parameter in the setup message identifying each VN and the DN in the selected route. Whether or not bandwidth can be allocated to the connection/bandwidth-allocation request on a route is determined by the QoS resource management rules, which entail determining link state and comparing the link load state to a depth-of-search (DoS) parameter sent in the setup message. The allowed DoS is based on the bandwidth-in-progress, link load state, routing priority, and whether the route is a first choice route or alternate route. If the first choice route cannot be accessed, a VN or DN returns control to the ON through the use of a crankback/bandwidth-not-available parameter in the release message, and at that point the ON may then try alternate routes as determined by FR, TDR, SDR, or EDR route selection rules outlined in ANNEX A.2. Whether or not bandwidth can be allocated to the connection/bandwidth-allocation request on the alternate route again is determined by the use of the DoS parameter compared to the link load state on each link in the alternate route. Example mechanisms to allocate and reserve bandwidth are now described. Analogous mechanisms have been used in practice and have been the subject of extensive studies [A98]. QoS resource management 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, such as link characteristics, Q.931 message information elements, information interchange (II) digits, and service control point (SCP) routing information, are used to derive the QoS resource management parameters, which include SI, VNET, and link capability (LC). 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 such as 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 Ash, Lee [Page 18] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 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. 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 In the 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. Ash, Lee [Page 19] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 Determination of the link load states is necessary 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 setup message. 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 crankback/bandwidth-not-available message 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 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 Ash, Lee [Page 20] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 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 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. QoS resource management 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. <
> Ash, Lee [Page 21] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 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 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 route selection 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 Ash, Lee [Page 22] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 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 may be 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 preferred characteristic will be used next. A LC preference may be 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 QoS bandwidth management procedure at the time of connection request set-up, a QoS priority of service queuing capability is used during the time the connection is established. At each link, a queuing discipline is maintained 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.5 Harmonization of Routing Methods Standards Harmonization of routing methods standards is needed 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. It is expected that this Recommendation drives the ITU-T side of the needed routing method functionality. In the ATM Forum, modification to recommendations identified in Table 1, column 4, are in progress. See for example [AM99], which addresses the QoS resource management issues. Other contributions to the ATM Forum are necessary to address a) needed routing table management functionality, which includes query-for-status and routing-recommendation methods, b) needed route selection functionality, which includes time dependent routing and event dependent routing. In the IETF, modification to recommendations identified in Table 1, column 5, are in progress. See for example [AAJL99], which addresses the QoS resource management issues. Other contributions to the IETF are necessary to address c) needed routing table management functionality, which includes query-for-status and routing-recommendation methods, d) needed route selection functionality, which includes time dependent routing and event dependent routing. Ash, Lee [Page 23] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 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. 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] for ISUP+ virtual trunking, [H.323] for the H.323 protocol, and in [HSSR99] for the session initiation protocol (SIP). Connection control and SVP/CRLDP control protocols are described for example in [Q.2761] for B-ISUP, [ATM960055] for PNNI signaling, [ATM960061] for UNI signaling, [DN99] for SVP signaling, and in [J99] for the MPLS/CRLDP signaling. Ash, Lee [Page 24] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 Table 4 Signaling and Information-Exchange Parameters to Support Routing Methods -------------------------------------------------------------------- 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 IAM SETUP FFS SETUP FFS IAM+ IAM+ Translation/ AESA FFS SETUP FFS SETUP FFS IAM+ IAM+ Routing IP Address FFS FFS IP PKT. FFS IP PKT. HEADER HEADER MEGACO, MEGACO, H.323, H.323, SIP SIP -------------------------------------------------------------------- Routing Topology Update FFS HELLO HELLO HELLO HELLO PTSE LSA PTSE LSA Table Status Update E.DYN PTSE LSA PTSE LSA Management Query for E.DYN FFS FFS FFS FFS Status Routing Recom. E.DYN FFS FFS FFS FFS -------------------------------------------------------------------- Route Fixed Routing IAM SETUP LABEL SETUP LABEL RELEASE RELEASE REQUEST RELEASE REQUEST BW MOD NOTIFY BW MOD NOTIFY BW REJT BW REJT Selection Time Dep. Rtg. IAM FFS FFS FFS FFS RELEASE State Dep. Rtg. IAM SETUP LABEL SETUP LABEL RELEASE RELEASE REQUEST RELEASE REQUEST BW MOD NOTIFY BW MOD NOTIFY BW REJT BW REJT Event Dep. Rtg. IAM FFS FFS FFS FFS RELEASE -------------------------------------------------------------------- QoS Resource BW Allocation FFS SETUP LABEL SETUP LABEL Management & Protection RELEASE REQUEST RELEASE REQUEST BW MOD NOTIFY BW MOD NOTIFY BW REJT BW REJT Priority Rtg. FFS SETUP LABEL SETUP LABEL RELEASE REQUEST RELEASE REQUEST BW MOD NOTIFY BW MOD NOTIFY BW REJT BW REJT Priority FFS SETUP LABEL SETUP LABEL Queuing RELEASE REQUEST RELEASE REQUEST BW MOD NOTIFY BW MOD NOTIFY BW REJT BW REJT -------------------------------------------------------------------- Ash, Lee [Page 25] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 FFS = for further study STANDARD NAME = denotes a standard currently in progress which, when complete, will support the routing method 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 standards for the five network technologies identified. That is, it is recommended that standards be developed for all information-exchange parameters not currently supported, which are identified in Table 4 as items for further study (FFS). 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 In Sections 7.2 to 7.4, we describe, respectively the routing-table-management, route selection, and QoS resource management information-exchange parameters recommended in Table 4. APPENDICES A-C describe the information-exchange parameters supported within each network type by either current standards or standards currently in progress. These are the basis for the recommended information-exchange parameters which are summarized in the Sections 7.1 to 7.3.. Please refer to the appropriate Section in the ANNEX(s) for more details and examples. In Section 7.4, 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 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 parameter: Provides for the automatic updating of nodes, links, and reachable addresses in the topology database. Ash, Lee [Page 26] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 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 parameter: Provides for an ON to DN or ON to RP link and/or node status request. 4. Routing-status-element parameter: Provides for a node to RP or DN to ON link and/or node status information. 5. Routing-recommendation-element parameter: Provides for an RP to node routing recommendation. These information exchange parameters are being standardized with Recommendation [E.DYN], and are recommended to be extended to ATM- and IP-based network environments. 7.2 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 release messages, 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. Forward information exchange is used in connection/bandwidth-allocation setup, and includes for example the following parameters: 6. Setup with DTL/ER parameter: The designated-transit-list (DTL) parameter in PNNI or the explicit route (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. 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 parameter: The crankback/bandwidth-not-available parameter in the release message 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 crankback/bandwidth-not-available parameter be included (as appropriate) in the RELEASE message for TDM-based networks, the SVC RELEASE and SVP MODIFY REJECT message for ATM-based networks, and CRLDP NOTIFY message for IP-based networks. This parameter is used to allow the ON to search out additional bandwidth on additional SVC/SVP/CRLSPs, as discussed in ANNEX A.4, B.4, and C.4. Ash, Lee [Page 27] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 7.3 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 DoS parameter: The depth-of-search (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. 9. Setup with modify parameter: The modify 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. It is recommended that the DTL/ER, DoS, and modify parameters be included (as appropriate) in the initial address message (IAM) for TDM-based networks, the SVC/SVP SETUP message and SVP MODIFY REQUEST message for ATM-based networks, and CRLDP LABEL REQUEST message for IP-based networks. These parameters are used to control the route routing, bandwidth allocation, and routing/queuing priorities, as discussed in ANNEX A.4, B.4, and C.4. 7.4 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. It is expected that this Recommendation drives the ITU-T side of the needed information-exchange functionality. In the ATM Forum, modification to recommendations identified in Table 4, column 4, are in progress. See for example [AM99], which addresses the QoS resource management issues. Other contributions to the ATM Forum are necessary to address e) needed routing table management information-exchange functionality, which includes query-for-status and routing-recommendation methods, f) needed route selection information-exchange functionality, which includes time dependent routing and event dependent routing. In the IETF, modification to recommendations identified in Table 4, column 5, are in progress. See for example [AAJL99], which addresses the QoS resource management issues. Other contributions to the IETF are necessary to address g) needed routing table management information-exchange functionality, which includes query-for-status and routing-recommendation methods, h) needed route selection information-exchange functionality, which includes time dependent routing and event dependent routing. Ash, Lee [Page 28] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 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. <
> 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 DoS parameter in the connection/bandwidth-allocation request setup message. 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 DoS parameter in the connection/bandwidth-allocation request setup message. 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 crankback/bandwidth-not-available parameter in the release message. If now node a4 finds that link d4-b1 has sufficient idle bandwidth capacity based on the status response message 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 setup message. 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 DoS parameter in the setup message. Node d4 then Ash, Lee [Page 29] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 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 crankback/bandwidth-not-available parameter in the release message. 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 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 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 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 DoS parameter in the connection/bandwidth-allocation request setup message. 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 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 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 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 DoS parameter in the connection/bandwidth-allocation request setup message. 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 crankback/bandwidth-not-available parameter in the release message. If now node b1 finds that route b1-d4-d3-a4 has sufficient idle bandwidth capacity based on the status messages 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 DoS parameter in the setup message. In that case node d4 tries to seize idle bandwidth on link d4-d3, and assuming that there is Ash, Lee [Page 30] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 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 DoS parameter in the setup message. Node d3 then routes the connection/bandwidth-allocation request on link d3-a4 to node a4, which is expected based on status information 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 crankback/bandwidth-not-available parameter in the release message. 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. 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. 9.0 Authors' Addresses Gerald R. Ash AT&T 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 Room MT C5-2D20 200 Laurel Avenue Middletown, NJ 07748 Phone: 732-420-4477 Fax: 732-368-6697 Email: younglee@att.com Ash, Lee [Page 31] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 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. 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. Ash, Lee [Page 32] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 In ITU-T Recommendations E.170, E.177, and E.DYN, 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.DYN. 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 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) Ash, Lee [Page 33] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 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 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.DYN. 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 Ash, Lee [Page 34] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 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.DYN. 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.DYN. 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.DYN. 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 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.DYN. 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. Ash, Lee [Page 35] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 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. A.4 TDM-Based Signaling and Information Exchange TDM-based network call control signaling protocols are described for example in [T1S198, ATM990048] for ISUP+ virtual trunking, and in [Q.2761] for the Broadband ISDN Used Part (B-ISUP) signaling protocol. We summarize here the information exchange required between network elements to implement the TDM-based route selection methods, which include connection control information required for connection set up, routing table design information required for routing table generation, and topology update information required for the automatic update and synchronization of topology databases. A.4.1 Connection/Bandwidth-Allocation Control Information Connection/bandwidth-allocation control information is used in connection/bandwidth-allocation set up to seize bandwidth in links, to release bandwidth in links, and for purposes of advancing route choices in the routing table. Existing connection/bandwidth-allocation setup and release messages, as described in Recommendations Q.71 and Q.2761, can be used with additional parameters to control route selection, DoS on a link, or crankback/bandwidth-not-available to an ON for 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. Recommendation [E.DYN] specifies and recommends the information exchange discussed below. Forward information exchange is used in connection/bandwidth-allocation set up, and includes for example the following parameters: 1. SETUP-DTL/ER: The designated-transit-list/explicit-route (DTL/ER) parameter specifies each VN and the DN in the route, and used by each VN to determine the next node in the route. 2. SETUP-DoS: 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. In B-ISUP these parameters could be carried in the initial address message (IAM). Backward information exchange is used to release a connection/bandwidth-allocation on a link such as from a DN to a VN or from a VN to an ON, and includes for example the following parameter: 3. RELEASE-CB: The crankback/bandwidth-not-available parameter in the release message is sent from the VN to ON or DN to ON, and allows for possible further alternate routing at the ON. Ash, Lee [Page 36] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 In B-ISUP signaling this parameter could be carried in the RELEASE message. A.4.2 Routing Table Management Information. 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. The following messages can be considered for this function: 4. QUERY: Provides for an ON to DN or ON to RP link and/or node status request. 5. STATUS: Provides ON/VN/DN to RP or DN to ON link and/or node status information. 6. RECOM: Provides for an RP to ON/VN/DN routing recommendation. These information exchange messages are already deployed in non-standard TDM-based implementations, and need to be extended to standard TDM-based network environments. In order to achieve automatic update and synchronization of the topology database, which is essential for routing table design, TDM-based networks need to interpret at the gateway switches the Hello protocol mechanisms of ATM- and IP-based networks to identify links in the network, as discussed in ANNEX B.4 for ATM-based networks. Also needed for topology database synchronization is a mechanism analogous to the PNNI topology state element (PTSE) exchange, as discussed in ANNEX B.4, which automatically provisions switches, links, and reachable addresses in the topology database. These extensions are recommended in Section 7. A.4.3 Examples of Information Exchange In this Section we illustrate the use of information exchange in setting up a connection/bandwidth-allocation request for the routing methods discussed in Section A.2. Here we show the use of the forward and backward information exchange used for connection/bandwidth-allocation control and routing table design purposes. A connection/bandwidth-allocation set-up example is now given, which applies to FR, TDR, SDR, and EDR route selection. The first step is for the ON to identify the DN and the routing table information for routing a connection/bandwidth-allocation request 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 in the SETUP-DTL parameter of the SETUP message, along with the DoS threshold in the SETUP-DoS parameter, to all nodes in the route. Each VN tests the available bandwidth capacity on each link in the route against the SETUP-DoS DoS threshold. If there is sufficient bandwidth capacity, the VN forwards the connection/bandwidth-allocation setup to the next node specified in the SETUP-DTL parameter, and the next node then performs a similar function. If there is insufficient bandwidth capacity, the VN sends a release message with crankback/bandwidth-not-available parameter RELEASE-CB back to the ON, at which point the ON tries the next route in the route as determined by the routing table rules. Ash, Lee [Page 37] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 Routing table design information flow examples are now discussed for the three cases of SDR, as described in Section A.2.3. In centralized periodic SDR, for example, each node periodically (say every 10 seconds) sends forward STATUS information to the routing processor (RP), which communicates the necessary load and traffic status information to the RP. In return the RP sends routing recommendation RECOM information to each node periodically (say every 10 seconds), which contain alternate route information for each ON-DN node pair. In distributed periodic SDR, for example, each node periodically (say every 5 minutes) sends forward STATUS information to every other node, which communicates the necessary load and traffic status information. In distributed call-by-by SDR, for example, following a first step in which the ON tries and fails to set up a connection/bandwidth-allocation request on the first choice direct route, the ON then sends a forward status QUERY request to the DN. The DN responds to the ON with backward STATUS information, which contains the load and traffic status information. In each of these examples, the status information is used by the ON or RP for routing table design, as discussed in Section A.2.3. Ash, Lee [Page 38] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 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 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 Ash, Lee [Page 39] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 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 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. <
> Ash, Lee [Page 40] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 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. 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 proposed 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 and BICI) protocols. In the proposed 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 routes (SVPs) constituting the VN bandwidth capacity. An earlier contribution specified example methods for SVC-based QoS resource management [AM98]. In [AM99] we propose 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 proposed 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 Ash, Lee [Page 41] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 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 propose 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 proposed 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 proposed 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 allowed according to QoS resource management criteria. If a subsequent link is not allowed, then the SVP modify reject message with a proposed 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 proposed 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 proposed 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 B2, 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, VN priority, and bandwidth allocation thresholds [AM98, ACFM99], as follows: Ash, Lee [Page 42] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 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 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 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. 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 propose to use the Diffserv parameter proposed in [ATM990097] to accommodate the SVC priority of service parameters in the setup signaling message. The Diffserv parameter will also provide the Ash, Lee [Page 43] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 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 requirements for SVP and SVC QoS resource management in ATM networks, as proposed 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 bandwidth request, to allow the ON to search out the additional bandwidth on additional SVPs. B.4 ATM-Based Signaling and Information Exchange ATM-based network call control signaling protocols are described for example in [ATM990048] for ISUP+ virtual trunking, and [Q.2761] for the Broadband ISDN Used Part (B-ISUP) signaling protocol. Connection/bandwidth-allocation control signaling protocols are described for example in [ATM960055] for the PNNI signaling protocol and in [ATM960061] for the UNI signaling protocol. We summarize here the information exchange required between network elements to implement the ATM-based route selection methods, which include connection/bandwidth-allocation control information required for connection/bandwidth-allocation set up, routing table design information required for routing table generation, and topology update information required for the automatic update and synchronization of topology databases. B.4.1 Connection/Bandwidth-Allocation Control Information Connection/bandwidth-allocation control information is used in connection/bandwidth-allocation set up to seize bandwidth in links, to release bandwidth in links, and to advance route choices in the routing table. Existing connection/bandwidth-allocation setup and release messages, as described in [ATM960055], can be used with additional parameters to control SVP bandwidth modification, DoS on a link, or SVP bandwidth-not-available to an ON for 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. Forward information exchange is used in connection/bandwidth-allocation set up, and includes for example the following parameters: 1. SETUP-DTL/ER: The designated-transit-list/explicit-route (DTL/ER) parameter in PNNI specifies each VN and the DN in the route, and used by each VN to determine the next node in the route. 2. SETUP-DoS: The DoS parameter used by each VN to compare the load state on the link to the allowed DoS to determine if the SVC connection/bandwidth-allocation request is admitted or blocked on that link. Ash, Lee [Page 44] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 3. MODIFY REQUEST - DoS: The DoS parameter used by each VN to compare the load state on the link to the allowed DoS to determine if the SVP modification request is admitted or blocked on that link. It is recommended in [AM99] that the DoS parameter be carried in the SVP MODIFY REQUEST and SVC SETUP messages, to control the bandwidth allocation and queuing priorities. For SVC setup with the DoS parameter, we may consider the use of the Diffserv information element proposed in [ATM990097] to accommodate the DoS parameters in the setup signaling message. 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 includes for example the following parameter: 4. RELEASE-CB: The crankback/bandwidth-not-available parameter in the release message is sent from the VN to ON or DN to ON, and allows for possible further alternate routing at the ON. 5. MODIFY REJECT-BNA: The bandwidth-not-available parameter in the modify reject message is sent from the VN to ON or DN to ON, and allows for possible further alternate routing at the ON to search out additional bandwidth on alternate SVPs. SVC crankback/bandwidth-not-available is already defined for PNNI-based signaling. We propose a bandwidth-not-available parameter in the SVP MODIFY REJECT message to allow the ON to search out additional bandwidth on additional SVPs. B.4.2 Routing Table Management Information. Routing table design 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, and in the case of PNNI a flooding mechanism of PTSE information is used. 6. PTSE: Provides for the automatic updating of link status, such as available bit rate (AvBR) information. B.4.3 Topology Update Information. In order to achieve automatic update and synchronization of the topology database, which is essential for routing table design, ATM-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 to automatically provision nodes, links, and reachable addresses in the topology database. 7. HELLO: Provides for the identification of links between nodes in the network. 8. PTSE: Provides for the automatic updating of nodes, links, and reachable addresses in the topology database. In summary, ATM-based networks already incorporate standard signaling and messaging directly applicable to routing implementation, which includes the DTL, crankback/bandwidth-not-available, HELLO, and PTSE capabilities. Additional requirements needed to support QoS resource management include the DoS parameter in the SVC SETUP and SVP MODIFY REQUEST messages, the bandwidth-not-available parameter in the SVP MODIFY REJECT message, as proposed in [AM99], and the support for QUERY, STATUS, and RECOM routing table design information exchange, as recommended in Section 7. Ash, Lee [Page 45] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 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. Therefore we make several assumptions 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 routes (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. 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. Ash, Lee [Page 46] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 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. Work is underway in the TIPHON (telecommunications and internet protocol harmonization over networks) effort [ETSIa, ETSIb, ETSIc, ETSId, ETSIe] to interwork between IP addressing and E.164 numbering/addressing. TIPHON is proposing a translation database 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 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 Ash, Lee [Page 47] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 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 proposed 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 proposed 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 routes (CRLSPs) constituting the VN bandwidth capacity. [AAJL99] proposes 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 proposed 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 proposed CRLDP notification message with crankback/bandwidth-not-available parameter allows the ON to search out possible bandwidth allocation on another CRLSP. In particular, [AAJL99] proposes 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] proposes an optional modify-TLV parameter in the CRLDP label request message to Ash, Lee [Page 48] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 allow dynamic modification of the assigned traffic parameters (such as peak data rate, committed data rate, etc.) of an already existing CRLSP. Finally, [AAJL99] proposes 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 Figure 1, ON A determines a list of shortest routes by using, for example, Dijkstra's algorithm. This route list could be determined based on administrative 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 Ash, Lee [Page 49] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 dependent routing (EDR) route selection [A98]. For example, in using the first CRLSP A-B-E in Figure C1, 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 proposed 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 proposed 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 proposed 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 proposed 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 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), Ash, Lee [Page 50] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 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 proposed 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 proposed 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 Figure C1, 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 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 Ash, Lee [Page 51] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 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 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 Ash, Lee [Page 52] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 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 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 Ash, Lee [Page 53] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 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 C2. <
> 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] makes these proposals 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. C.4 IP-Based Signaling and Information Exchange IP-based call control signaling protocols are described for example in [H.323] for the H.323 protocol and in [HSSR99] for the session initiation protocol (SIP). IP-based MPLS/CRLDP CRLSP control protocols are described for example in [CDFFSV97] and [J99]. CRLSPs are the bandwidth segments over which the call control signaling protocols establish connections. We summarize here the information exchange required between network elements to implement the IP-based route selection methods, which include CRLSP control information required for connection/bandwidth-allocation set up, routing table design information required for routing table generation, and topology update information required for the automatic update and synchronization of topology databases. Ash, Lee [Page 54] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 C.4.1 Bandwidth-Allocation Control Information Bandwidth-allocation control information is used to seize and modify bandwidth allocation on LSPs, to release bandwidth on LSPs, and for purposes of advancing the LSP choices in the routing table. Existing CRLSP label request (setup) and notify (release) messages, as described in [J99], can be used with additional parameters to control CRLSP bandwidth modification, DoS on a link, or CRLSP crankback/bandwidth-not-available to an ON for further alternate routing to search out additional bandwidth on alternate CRLSPs. Actual selection of a CRLSP is determined from the routing table, and CRLSP control information is used to establish the route choice. Forward information exchange is used in CRLSP set up and bandwidth modification, and includes for example the following parameters: 1. LABEL REQUEST - ER: The explicit route (ER) parameter in CRLDP specifies each VN and the DN in the CRLSP, and used by each VN to determine the next node in the route. 2. LABEL REQUEST - DoS: The DoS parameter is used by each VN to compare the load state on each CRLSP link to the allowed DoS threshold to determine if the CRLDP setup or modification request is admitted or blocked on that link. 3. LABEL REQUEST - MODIFY: The MODIFY parameter is used by each VN/DN to update the traffic parameters (e.g., committed data rate) on an existing CRLSP to determine if the CRLDP modification request is admitted or blocked on each link in the CRLSP. We propose a DoS TLV parameter in the CRLDP LABEL REQUEST message to control the bandwidth allocation and queuing priorities and a MODIFY TLV parameter to control the bandwidth modification on an existing CRLSP. 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 includes for example the following parameter: 4. NOTIFY-CB: The crankback/bandwidth-not-available parameter in the notify (release) message sent from the VN to ON or DN to ON, and allows for possible further alternate routing at the ON to search out alternate CRLSPs for additional bandwidth. We propose a crankback/bandwidth-not-available TLV parameter in the CRLDP NOTIFY message to allow the ON to search out additional bandwidth on additional CRLSPs. C.4.2 Routing Table Management Information. Routing table design 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, and in the case of OSPF a flooding mechanism of LSA information is used. 5. LSA: Provides for the automatic updating of link status, such as available bit rate information. C.4.3 Topology Update Information In order to achieve automatic update and synchronization of the topology database, which is essential for routing table design, IP-based networks Ash, Lee [Page 55] Internet Draft Routing Across TDM-, ATM-, & IP-Based Networks May 99 already interpret HELLO protocol mechanisms to identify links in the network. For topology database synchronization the OSPF link state advertisement (LSA) exchange is used to automatically provision nodes, links, and reachable addresses in the topology database. 6. HELLO: Provides for the identification of links between nodes in the network. 7. LSA: Provides for the automatic updating of nodes, links, and reachable addresses in the topology database. In summary, IP-based networks already incorporate standard signaling and directly applicable to routing implementation, which includes the ER, HELLO, and LSA capabilities. Additional requirements needed to support QoS resource management include the DoS TLV parameter and MODIFY TLV parameter in the CRLDP LABEL REQUEST message, the crankback/bandwidth-not-available TLV parameter in the CRLDP notify message, as proposed in [AALJ99], and the support for QUERY, STATUS, and RECOM routing table design information exchange, as recommended in Section 7. Call control with the H.323 and session initiation protocol [HSSR99] protocols needs to be coordinated with MPLS/CRLDP CRLSP connection/bandwidth-allocation control. Ash, Lee [Page 56]