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]