1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011
|
Network Working Group Y. Katsube
Request for Comments: 2098 K. Nagami
Category: Informational H. Esaki
Toshiba R&D Center
February 1997
Toshiba's Router Architecture Extensions for ATM : Overview
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
This memo describes a new internetworking architecture which makes
better use of the property of ATM. IP datagrams are transferred
along hop-by-hop path via routers, but datagram assembly/disassembly
and IP header processing are not necessarily carried out at
individual routers in the proposed architecture. A concept of "Cell
Switch Router (CSR)" is introduced as a new internetworking
equipment, which has ATM cell switching capabilities in addition to
conventional IP datagram forwarding. Proposed architecture can
provide applications with high-throughput and low-latency ATM pipes
while retaining current router-based internetworking concept. It
also provides applications with specific QoS/bandwidth by cooperating
with internetworking level resource reservation protocols such as
RSVP.
1. Introduction
The Internet is growing both in its size and its traffic volume. In
addition, recent applications often require guaranteed bandwidth and
QoS rather than best effort. Such changes make the current hop-by-
hop datagram forwarding paradigm inadequate, then accelerate
investigations on new internetworking architectures.
Roughly two distinct approaches can be seen as possible solutions;
the use of ATM to convey IP datagrams, and the revision of IP to
support flow concept and resource reservation. Integration or
interworking of these approaches will be necessary to provide end
hosts with high throughput and QoS guaranteed internetworking
services over any datalink platforms as well as ATM.
New internetworking architecture proposed in this draft is based on
"Cell Switch Router (CSR)" which has the following properties.
Katsube, et. al. Informational [Page 1]
RFC 2098 Toshiba's Router Extension for ATM February 1997
- It makes the best use of ATM's property while retaining current
router-based internetworking and routing architecture.
- It takes into account interoperability with future IP that
supports flow concept and resource reservations.
Section 2 of this draft explains background and motivations of our
proposal. Section 3 describes an overview of the proposed
internetworking architecture and its several remarkable features.
Section 4 discusses control architectures for CSR, which will need to
be further investigated.
2. Background and Motivation
It is considered that the current hop-by-hop best effort datagram
forwarding paradigm will not be adequate to support future large
scale Internet which accommodates huge amount of traffic with certain
QoS requirements. Two major schools of investigations can be seen in
IETF whose main purpose is to improve ability of the Internet with
regard to its throughput and QoS. One is to utilize ATM technology
as much as possible, and the other is to introduce the concept of
resource reservation and flow into IP.
1) Utilization of ATM
Although basic properties of ATM; necessity of connection setup,
necessity of traffic contract, etc.; is not necessarily suited to
conventional IP datagram transmission, its excellent throughput and
delay characteristics let us to investigate the realization of IP
datagram transmission over ATM.
A typical internetworking architecture is the "Classical IP Model"
[RFC1577]. This model allows direct ATM connectivities only between
nodes that share the same IP address prefix. IP datagrams should
traverse routers whenever they go beyond IP subnet boundaries even
though their source and destination are accommodated in the same ATM
cloud. Although an ATMARP is introduced which is not based on legacy
datalink broadcast but on centralized ATMARP servers, this model does
not require drastic changes to the legacy internetworking
architectures with regard to the IP datagram forwarding process.
This model still has problems of limited throughput and large
latency, compared with the ability of ATM, due to IP header
processing at every router. It will become more critical when
multimedia applications that require much larger bandwidth and lower
latency become dominant in the near future.
Katsube, et. al. Informational [Page 2]
RFC 2098 Toshiba's Router Extension for ATM February 1997
Another internetworking architecture is "NHRP (Next Hop Resolution
Protocol) Model" [NHRP09]. This model aims at resolving throughput
and latency problems in the Classical IP Model and making the best
use of ATM. ATM connections can be directly established from an
ingress point to an egress point of an ATM cloud even when they do
not share the same IP address prefix. In order to enable it, the
Next Hop Server [KAT95] is introduced which can find an egress point
of the ATM cloud nearest to the given destination and resolves its
ATM address. A sort of query/response protocols between the
server(s) and clients and possibly server and server are specified.
After the ATM address of a desired egress point is resolved, the
client establishes a direct ATM connection to that point through ATM
signaling procedures [ATM3.1]. Once a direct ATM connection has been
set up through this procedure, IP datagrams do not have to experience
hop-by-hop IP processing but can be transmitted over the direct ATM
connection. Therefore, high throughput and low latency
communications become possible even if they go beyond IP subnet
boundaries. It should be noted that the provision of such direct ATM
connections does not mean disappearance of legacy routers which
interconnect distinct ATM-based IP subnets. For example, hop-by-hop
IP datagram forwarding function would still be required in the
following cases:
- When you want to transmit IP datagrams before direct ATM connection
from an ingress point to an egress point of the ATM cloud is
established
- When you neither require a certain QoS nor transmit large amount of
IP datagrams for some communication
- When the direct ATM connection is not allowed by security or policy
reasons
2) IP level resource reservation and flow support
Apart from investigation on specific datalink technology such as ATM,
resource reservation technologies for desired IP level flows have
been studied and are still under discussion. Their typical examples
are RSVP [RSVP13] and STII [RFC1819].
RSVP itself is not a connection oriented technology since datagrams
can be transmitted regardless of the result of the resource
reservation process. After a resource reservation process from a
receiver (or receivers) to a sender (or senders) is successfully
completed, RSVP-capable routers along the path of the flow reserve
their resources for datagram forwarding according to the requested
flow spec.
Katsube, et. al. Informational [Page 3]
RFC 2098 Toshiba's Router Extension for ATM February 1997
STII is regarded as a connection oriented IP which requires
connection setup process from a sender to a receiver (or receivers)
before transmitting datagrams. STII-capable routers along the path
of the requested connection reserve their resources for datagram
forwarding according to the flow spec.
Neither RSVP nor STII restrict underlying datalink networks since
their primary purpose is to let routers provide each IP flow with
desired forwarding quality (by controlling their datagram scheduling
rules). Since various datalink networks will coexist as well as ATM
in the future, these IP level resource reservation technologies would
be necessary in order to provide end-to-end IP flow with desired
bandwidth and QoS.
aking this background into consideration, we should be aware of
several issues which motivate our proposal.
- As of the time of writing, the ATM specific internetworking
architecture proposed does not take into account interoperability
with IP level resource reservation or connection setup protocols.
In particular, operating RSVP in the NHRP-based ATM cloud seems to
require much effort since RSVP is a soft-state receiver-oriented
protocol with multicast capability as a default, while ATM with
NHRP is a hard-state sender-oriented protocol which does not
support multicast yet.
- Although RSVP or STII-based routers will provide each IP flow with
a desired bandwidth and QoS, they have some native throughput
limitations due to the processor-based IP forwarding mechanism
compared with the hardware switching mechanism of ATM.
The main objective of our proposal is to resolve the above issues.
The proposed internetworking architecture makes the best use of the
property of ATM by extending legacy routers to handle future IP
features such as flow support and resource reservation with the help
of ATM's cell switching capabilities.
3. Internetworking Architecture Based On the Cell Switch Router (CSR)
3.1 Overview
The Cell Switch Router (CSR) is a key network element of the proposed
internetworking architecture. The CSR provides cell switching
functionality in addition to conventional IP datagram forwarding.
Communications with high throughput and low latency, that are native
properties of ATM, become possible by using this cell switching
functionality even when the communications pass through IP subnetwork
Katsube, et. al. Informational [Page 4]
RFC 2098 Toshiba's Router Extension for ATM February 1997
boundaries. In an ATM internet composed of CSRs, VPI/VCI-based cell
switching which bypasses datagram assembly/disassembly and IP header
processing is possible at every CSR for communications which lend
themselves to such (e.g., communications which require certain amount
of bandwidth and QoS), while conventional hop-by-hop datagram
forwarding based on the IP header is also possible at every CSR for
other conventional communications.
By using such cell-level switching capabilities, the CSR is able to
concatenate incoming and outgoing ATM VCs, although the concatenation
in this case is controlled outside the ATM cloud (ATM's control/
management-plane) unlike conventional ATM switch nodes. That is, the
CSR is attached to ATM networks via an ATM-UNI instead of NNI. By
carrying out such VPI/VCI concatenations at multiple CSRs
consecutively, ATM level connectivity composed of multiple ATM VCs,
each of which connects adjacent CSRs (or CSR and hosts/routers), can
be provided. We call such an ATM pipe "ATM Bypass-pipe" to
differentiate it from "ATM VCC (VC connection)" provided by a single
ATM datalink cloud through ATM signaling.
Example network configurations based on CSRs are shown in figure 1.
An ATM datalink network may be a large cloud which accommodates
multiple IP subnets X, Y and Z. Or several distinct ATM datalinks
may accommodate single IP subnet X, Y and Z respectively. The latter
configuration would be straightforward in discussing the CSR, but the
CSR is also applicable to the former configuration as well. In
addition, the CSR would be applicable as a router which interconnects
multiple NHRP-based ATM clouds.
Two different kinds of ATM VCs are defined between adjacent CSRs or
between CSR and ATM-attached hosts/routers.
1) Default-VC
It is a general purpose VC used by any communications which select
conventional hop-by-hop IP routed paths. All incoming cells received
from this VC are assembled to IP datagrams and handled based on their
IP headers. VCs set up in the Classical IP Model are classified into
this category.
2) Dedicated-VC
It is used by specific communications (IP flows) which are specified
by, for example, any combination of the destination IP address/port,
the source IP address/port or IPv6 flow label. It can be
concatenated with other Dedicated-VCs which accommodate the same IP
flow as it, and can constitute an ATM Bypass-pipe for those IP flows.
Katsube, et. al. Informational [Page 5]
RFC 2098 Toshiba's Router Extension for ATM February 1997
Ingress/egress nodes of the Bypass-pipe can be either CSRs or ATM-
attached routers/hosts both of which speak a Bypass-pipe control
protocol. (we call that "Bypass-capable nodes") On the other hand,
intermediate nodes of the Bypass-pipe should be CSRs since they need
to have cell switching capabilities as well as to speak the Bypass-
pipe control protocol.
The route for a Bypass-pipe follows IP routing information in each
CSR. In figure 1, IP datagrams from a source host or router X.1 to a
destination host or router Z.1 are transferred over the route X.1 ->
CSR1 -> CSR2 -> Z.1 regardless of whether the communication is on a
hop-by-hop basis or Bypass-pipe basis. Routes for individual
Dedicated-VCs which constitutes the Bypass-pipe X.1 --> Z.1 (X.1 ->
CSR1, CSR1 -> CSR2, CSR2 -> Z.1) would be determined based on ATM
routing protocols such as PNNI [PNNI1.0], and would be independent of
IP level routing.
An example of IP datagram transmission mechanism is as follows.
o The host/router X.1 checks an identifier of each IP datagram,
which may be the "destination IP address (prefix)",
"source/destination IP address (prefix) pair", "destination IP
address and port", "source IP address and Flow label (in IPv6)",
and so on. Based on either of those identifiers, it determines
over which VC the datagram should be transmitted.
o The CSR1/2 checks the VPI/VCI value of each incoming cell. When
the mapping from the incoming interface/VPI/VCI to outgoing
interface/VPI/VCI is found in an ATM routing table, it is directly
forwarded to the specified interface through an ATM switch module.
When the mapping in not found in the ATM routing table (or the
table shows an IP module as an output interface), the cell is
assembled to an IP datagram and then forwarded to an appropriate
outgoing interface/VPI/VCI based on an identifier of the datagram.
Katsube, et. al. Informational [Page 6]
RFC 2098 Toshiba's Router Extension for ATM February 1997
IP subnet X IP subnet Y IP subnet Z
<---------------------> <-----------------> <--------------------->
+-------+ Default +-------+ Default +-------+ Default +-------+
| | -VC | CSR 1 | -VC | CSR 2 | -VC | |
| Host +=============+ +===============+ +=============+ Host |
| X.1 +-------------+++++---------------+++++-------------+ Z.1 |
| +-------------+++++---------------+++++-------------+ |
| +-------------+++++---------------+++++-------------+ |
| |Dedicated | | Dedicated | |Dedicated | |
+-------+ -VCs +-------+ -VCs +-------+ -VCs +-------+
<--------------------------------------------------->
Bypass-pipe
Figure 1 Internetworking Architecture based on CSR
3.2 Features
The main feature of the CSR-based internetworking architecture is the
same as that of the NHRP-based architecture in the sense that they
both provide direct ATM level connectivity beyond IP subnet
boundaries. There are, however, several notable differences in the
CSR-based architecture compared with the NHRP-based one as follows.
1) Relationship between IP routing and ATM routing
In the NHRP model, an egress point of the ATM network is first
determined in the next hop resolution phase based on IP level routing
information. Then the actual route for an ATM-VC to the obtained
egress point is determined in the ATM connection setup phase based on
ATM level routing information. Both kinds of routing information
would be calculated according to factors such as network topology and
available bandwidth for the large ATM cloud. The ATM routing will be
based on PNNI phase1 [PNNI1.0] while the IP routing will be based on
OSPF, BGP, IS-IS, etc. We need to manage two different routing
protocols over the large ATM cloud until Integtrated-PNNI [IPNNI96]
which takes both ATM level metric and IP level metric into account
will be phased in in the future.
In the CSR model, IP level routing determines an egress point of the
ATM cloud as well as determines inter-subnet level path to the point
that shows which CSRs it should pass through. ATM level routing
determines an intra-subnet level path for ATM-VCs (both Dedicated-VC
and Default-VC) only between adjacent nodes (CSRs or ATM-attached
hosts/routers). Since the roles of routing are hierarchically
subdivided into inter-subnet level (router level) and intra-subnet
level (ATM SW level), ATM routing does not have to operate all over
Katsube, et. al. Informational [Page 7]
RFC 2098 Toshiba's Router Extension for ATM February 1997
the ATM cloud but only in individual IP subnets independent from each
other. This will decrease the amount of information for ATM routing
protocol handling. But an end-to-end ATM path may not be optimal
compared with the NHRP model since the path should go through routers
at subnet boundaries in the CSR model.
2) Dynamic routing and redundancy support
A CSR-based network can dynamically change routes for Bypass-pipes
when related IP level routing information changes. Bypass-pipes
related to the routing changes do not have to be torn down nor
established from scratch since intermediate CSRs related to IP
routing changes can follow them and change routes for related
Bypass-pipes by themselves.
The same things apply when some error or outage happens in any ATM
nodes/links/routers on the route of a Bypass-pipe. CSRs that have
noticed such errors or outages would change routes for related
Bypass-pipes by themselves.
3) Interoperability with IP level resource reservation protocols in
multicast environments
As current NHRP specification assumes application of NHRP to unicast
environments only, multicast IP flows should still be carried based
on a hop-by-hop manner with multicast routers. In addition,
realization of IP level resource reservation protocols such as RSVP
over NHRP environments requires further investigation.
The CSR-based internetworking architecture which keeps subnet-by-
subnet internetworking with regard to any control protocol sequence
can provide multicast Bypass-pipes without requiring any
modifications in IP multicast over ATM [IPMC96] or multicast routing
techniques. In addition, since the CSR can handle RSVP messages
which are transmitted in a hop-by-hop manner, it can provide Bypass-
pipes which satisfy QoS requirements by the cooperation of the RSVP
and the Bypass-pipe control protocol.
4. Control Architecture for CSR
Several issues with regard to a control architecture for the CSR are
discussed in this section.
4.1 Network Reference Model
In order to help understanding discussions in this section, the
following network reference model is assumed. Source hosts S1, S2,
and destination hosts D1, D2 are attached to Ethernets, while S3 and
Katsube, et. al. Informational [Page 8]
RFC 2098 Toshiba's Router Extension for ATM February 1997
D3 are attached to the ATM. Routers R1 and R5 are attached to
Ethernets only, while R2, R3 and R4 are attached to the ATM. The ATM
datalink for subnet #3 and subnet #4 can either be physically
separated datalinks or be the same datalink. In other words, R3 can
be either one-port or multi-port router.
Ether Ether ATM ATM Ether Ether
| | +-----+ +-----+ | |
| | | | | | | |
S1--| S2---| S3---| | | |---D3 |---D2 |--D1
| | | | | | | |
|---R1---|---R2---| |--R3--| |---R4---|---R5---|
| | | | | | | |
| | +-----+ +-----+ | |
subnet subnet subnet subnet subnet subnet
#1 #2 #3 #4 #5 #6
Figure 2 Network Reference Model
Bypass-pipes can be configured [S3 or R2]-->R3-->[D3 or R4]. That
means that S3, D3, R2, R3 and R4 need to speak Bypass-pipe control
protocol, and means that R3 needs to be the CSR. We use term
"Bypass-capable nodes" for hosts/routers which can speak Bypass-pipe
control protocol but are not necessarily CSRs.
As shown in this reference model, Bypass-pipe can be configured from
host to host (S3-->R3-->D3), router to host (R2-->R3-->D3), host to
router (S3-->R3-->R4), and router to router (R2-->R3-->R4).
4.2 Possible Use of Bypass-pipe
Possible use (or purposes) of Bypass-pipe provided by CSRs, in other
words, possible triggers that initiate Bypass-pipe setup procedure,
is discussed in this subsection.
Following two purposes for Bypass-pipe setup are assumed at present;
a) Provision of low latency path
This indicates cases in which end hosts or routers initiate a
Bypass-pipe setup procedure when they will transmit large amount of
datagrams toward a specific destination. For instance,
- End hosts or routers initiate Bypass-pipe setup procedures based
on the measurement of IP datagrams transmitted toward a certain
destination.
Katsube, et. al. Informational [Page 9]
RFC 2098 Toshiba's Router Extension for ATM February 1997
- End hosts or routers initiate Bypass-pipe setup procedures when
it detects datagrams with certain higher layer protocols such as
ftp, nntp, http, etc.
Other triggers may be possible depending on the policy in each
network. In any case, the purpose of Bypass-pipe setup in each of
these cases is to reduce IP processing burden at intermediate routers
as well as to provide a communication path with low latency for burst
data transfer, rather than to provide end host applications with
specific bandwidth/QoS.
There would be no rule for determining bandwidth for such kinds of
Bypass-pipes since no explicit information about bandwidth/QoS
requirement by end hosts is available without IP-level resource
reservation protocols such as RSVP. Using UBR VCs as components of
the Bypass-pipe would be the easiest choice although there is no
guarantees for cell loss quality, while using other services such as
CBR/VBR/ABR with an adequate parameter tuning would be possible.
b) Provision of specific bandwidth/QoS requested by hosts
This indicates cases in which routers or end hosts initiate a
Bypass-pipe setup procedure by triggers related to IP-level
bandwidth/QoS request from end hosts. The "resource management
entity" in the host or router, which has received bandwidth/QoS
requests from applications or adjacent nodes may choose to
accommodate the requested IP flow to an existing VC or choose to
allocate a new Dedicated-VC for the requested IP flow. Selecting the
latter choice at each router can correspond to the trigger for
constituting a Bypass-pipe. When both an incoming VC and an outgoing
VC (or VCs) are dedicated to the same IP flow(s), those VCs can be
concatenated at the CSR (ATM cut-through) to constitute a Bypass-
pipe. Bandwidth for the Bypass-pipe (namely, individual VCs
constituting the Bypass-pipe) in this case would be determined based
on the bandwidth/QoS requirements by the end host which is conveyed
by, e.g., RSVP messages. The ATM service classes; e.g., CBR/VBR/ABR;
that would be selected depends on the IP-level service classes
requested by the end hosts.
Bypass-pipe provision for the purpose of b) will surely be beneficial
in the near future when related IP-level resource reservation
protocol will become available as well as when definitions of
individual service classes and flow specs offered to applications
become clear. On the other hand, Bypass-pipe setup for the purpose
of a) may be beneficial right now since it does not require
availability of IP-level resource reservation protocols. In that
sense, a) can be regarded as a kind of short-term use while b) is a
long-term use.
Katsube, et. al. Informational [Page 10]
RFC 2098 Toshiba's Router Extension for ATM February 1997
4.3 Variations of Bypass-pipe Control Architecture
A number of variations regarding Bypass-pipe control architecture are
introduced. Items which are related to architectural variations are;
o Ways of providing Dedicated-VCs
o Channels for Bypass-pipe control message transfer
o Bypass-pipe control procedures
Each of these items are discussed below.
4.3.1 Ways of Providing Dedicated-VCs
There are roughly three alternatives regarding the way of providing
Dedicated-VCs in individual IP subnets as components of a Bypass-
pipe.
a) On-demand SVC setup
Dedicated-VCs are set up in individual IP subnets each time you want
to set up a Bypass-pipe through the ATM signaling procedure.
b) Picking up one from a bunch of (semi-)PVCs
Several VCs are set up beforehand between CSR and CSR, or CSR and
other ATM-attached nodes (hosts/router) in each IP subnet. Unused VC
is picked up as a Dedicated-VC from these PVCs in each IP subnet when
a Bypass-pipe is set up.
c) Picking up one VCI in PVP/SVP
PVPs or SVPs are set up between CSR and CSR, or CSR and other ATM-
attached nodes (hosts/routers) in each IP subnet. PVPs would be set
up as a router/host initialization procedure, while SVPs, on the
other hand, would be set up through ATM signaling when the first VC
(either Default- or Dedicated-) setup request is initiated by either
of some peer nodes. Then, Unused VCI value is picked up as a
Dedicated-VC in the PVP/SVP in each IP subnet when a Bypass-pipe is
set up. The SVP can be released through ATM signaling when no VCI
value is in active state.
The best choice will be a) with regard to efficient network resource
usage. However, you may go through three steps, ATMARP (for unicast
[RFC1577] or multicast [IPMC96] in each IP subnet), SVC setup (in
each IP subnet) and exchange of Bypass-pipe control message in this
case. Whether a) is practical choice or not will depend on whether
Katsube, et. al. Informational [Page 11]
RFC 2098 Toshiba's Router Extension for ATM February 1997
you can allow larger Bypass-pipe setup time due to three-step
procedure mentioned above, or whether you can send datagrams over
Default-VCs in a hop-by-hop manner while waiting for the Bypass-pipe
set up.
In the case of b) or c), the issue of Bypass-pipe setup time will be
improved since SVC setup step can be skipped. In b), each node (CSR
or ATM-attached host/router) should specify some traffic descriptors
even for unused VCs, and the ATM datalink should reserve its desired
resource (such as VCI value and bandwidth) for them. In addition,
the ATM datalink may have to carry out UPC functions for those unused
VCs. Such burden would be reduced when you use UBR-PVCs and set peak
cell rate for each of them equal to link rate, but bandwidth/QoS for
the Bypass-pipe is not provided in this case. In c), on the other
hand, traffic descriptors which should be specified by each node for
the ATM datalink is not each VC's but VP's only. Resource
reservations for individual VCs will be carried out not as a
functionality of the ATM datalink but of each CSR or ATM-attached
host/router if necessary. A functionality which need to be provided
by the ATM datalink is control of VPs' bandwidth only such as UPC and
dynamic bandwidth negotiation if it would be widely available.
4.3.2 Channels for Bypass-pipe Control Message Transfer
There are several alternatives regarding the channels for managing
(setting up, releasing, and possibly changing the route of) a
Bypass-pipe. This subsection explains these alternatives and
discusses their properties.
Three alternatives are discussed, Inband control message, Outband
control message, and use of ATM signaling.
i) Inband Control Message
When setting up a Bypass-pipe, control messages are transmitted over
a Dedicated-VC which will eventually be used as a component of the
Bypass-pipe. These messages are handled at each CSR, and similar
messages are transmitted to the next-hop node over a Dedicated-VC
along the selected route (based on IP routing table). Unlike outband
message protocol described in ii), each message does not have to
indicate a Dedicated-VC which will be used since the message itself
is carried over "that" VC.
The inband control message can be either "datagram dedicated for
Bypass-pipe control" or "actual IP datagram" sent by user
application. Actual IP datagrams can be transmitted over Bypass-pipe
after it has been set up in the former case. In the latter case, on
the other hand, the first (or several) IP datagram(s) received from
Katsube, et. al. Informational [Page 12]
RFC 2098 Toshiba's Router Extension for ATM February 1997
an unused Dedicated-VC are analyzed at IP level and transmitted
toward adequate next hop over an unused Dedicated-VC. Then incoming
Dedicated-VC and outgoing Dedicated-VC are concatenated to construct
a Bypass-pipe.
In inband control, Bypass-pipe control messages transmitted after a
Bypass-pipe has been set up cannot be identified at intermediate CSRs
since those messages are forwarded at cell level there. As a
possible solution for this issue, intermediate CSRs can identify
Bypass-pipe control messages by marking cell headers, e.g., PTI bit
which indicates F5 OAM cell. With regard to Bypass-pipe release,
explicit release message may not be necessary if individual CSRs
administer the amount of traffic over each Dedicated-VC and deletes
concatenation information for an inactive Bypass-pipe with their own
decision.
ii) Outband Control Message
When a Bypass-pipe is set up or released, control messages are
transmitted over VCs which are different from Dedicated-VCs used as
components of the Bypass-pipe. Unlike inband message protocol
described in i), each message has to indicate which Dedicated-VCs the
message would like to control. Therefore, an identifier that
uniquely discriminates a VC, which is not a VPI/VCI that is not
identical at both endpoints of the VC, need to be defined and be
given at VC initiation phase. However, an issue of control message
transmission after a Bypass-pipe has been set up in inband case does
not exist.
Four alternatives are possible regarding how to convey Bypass-pipe
control messages hop-by-hop over ATM datalink networks.
1) Defines VC for Bypass-pipe control messages only.
2) Uses Default-VC and discriminates Bypass-pipe control messages
from user datagrams by an LLC/SANP value in RFC1483 encapsulation.
3) Uses Default-VC and discriminates Bypass-pipe control messages
from user datagrams by a protocol field value in IP header.
4) Uses Default-VC and discriminates Bypass-pipe control messages
from user datagrams by a port ID in the UDP frame.
When we take into account interoperability with Bypass-incapable
routers, 1) will not be a good choice. Whether we select 2) or 3) 4)
depends on whether we should consider multiprotocol rather than IP
only.
Katsube, et. al. Informational [Page 13]
RFC 2098 Toshiba's Router Extension for ATM February 1997
In the case of IP multicast, point-to-multipoint VCs in individual
subnets are concatenated at CSRs consecutively in order to constitute
end-to-end multicast tree. Above four alternatives may require the
same number of point-to-multipoint Defalut-VCs as the number of
requested point-to-multipoint Dedicated-VCs in multicast case. The
fifth alternative which can reduce the necessary number of VCs to
convey control messages in a multicast environment is;
5) Defines point-to-multipoint VC whose leaves are members of
multicast group 224.0.0.1. All nodes which are members of at
least one of active multicast group would become leaves of this
point-to-multipoint VC.
Each upstream node may become a root of the point-to-multipoint VC,
or a sort of multicast server to which each upstream node transmits
cells over a point-to-point VC may become a root of that. In any
case, Bypass-pipe control messages for every multicast group are
transmitted to all nodes which are members of either of the group.
When a downstream node has received control messages which are not
related to a multicast group it belongs, it should discard them by
referring to a destination group address on their IP header.
Donwstream node would still need to use point-to-point VC to send
control messages toward upstream.
iii) Use of ATM Signaling Message
Supposing that ATM signaling messages can convey IP addresses (and
possibly port IDs) of source and destination, it may be possible that
ATM signaling messages be used as Bypass-pipe control messages also.
In that case, an ATM connection setup message indicates a setup of a
Dedicated-VC to an ATM address of a desirable next-hop IP node, and
also indicates a setup of a Bypass-pipe to an IP address (and
possibly port ID) of a target destination node. Information elements
for the Dedicated-VC setup (ATM address of a next-hop node,
bandwidth, QoS, etc.) are handled at ATM nodes, while information
elements for the Bypass-pipe setup (source and destination IP
addresses, possibly their port IDs, or flow label for IPv6, etc.) are
transparently transferred to the next-hop IP node. The next-hop IP
node accepts Dedicated-VC setup and handles such IP level information
elements.
ATM signaling messages can be transferred from receiver to sender as
well as sender to receiver when you set zero Forward Cell Rate and
non-zero Backward Cell Rate as an ATM traffic descriptor information
element in unicast case, or when Leaf Initiated Join capabilities
will become available in multicast case.
Katsube, et. al. Informational [Page 14]
RFC 2098 Toshiba's Router Extension for ATM February 1997
Issues in this method are,
- Information elements which specify IP level (and port level)
information need to be defined, e.g., B-HLI or B-UUI, as an ATM
signaling specification.
- It would be difficult to support soft-state Bypass-pipe control
which transmits control messages periodically since ATM signaling
is a hard-state protocol.
4.3.3 Bypass-pipe Control Procedures
This subsection discusses several items with regard to actual
procedures for Bypass-pipe control.
a) Distributed trigger vs. Centralized (restricted) trigger
The first item to be discussed is whether the functionality of
detecting a trigger of Dedicated-VC/Bypass-pipe control is
distributed to all the nodes (including CSRs and hosts/edge devices)
or restricted to specific nodes.
In the case of the distributed trigger, every node is regarded as
having a capability of detecting a trigger of Bypass-pipe setup or
termination. For example, every node detects datagrams for ftp, and
sets up (or fetches) a Dedicated-VC individually to construct a
Bypass-pipe. After setting up or fetching the Dedicated-VCs,
messages which informs (or requests) the transmission of the IP flow
over the Dedicated-VC are exchanged between adjacent nodes. That
enables peer nodes to share the same knowledge about the mapping
relationship between the IP flow and the Dedicated-VC. There is no
end-to-end message transmission in the Bypass-pipe control procedure
itself, but transmission between adjacent nodes only.
In the case of the centralized (or restricted) trigger, capability of
detecting a trigger of Bypass-pipe setup or termination is restricted
to nodes which are located at "the boundary of the CSR-cloud". The
boundary of the CSR-cloud signifies, for individual IP flows, the
node which is the first-hop or the last-hop CSR-capable node. For
example, a node which detects datagrams for ftp can initiate Bypass-
pipe setup procedure only when its previous hop is non-ATM or CSR-
incapable. In this case, Bypass-pipe control messages are originated
at the boundary of the CSR-cloud, and forwarded hop-by-hop toward
another side of the boundary, which is similar to ATM signaling
messages. The semantics of the messages may be the request of end-
to-end Bypass-pipe setup as well as notification or request of
mapping relationship between the IP flow and the Dedicated-VC.
Katsube, et. al. Informational [Page 15]
RFC 2098 Toshiba's Router Extension for ATM February 1997
b) Upstream-initiated control vs. Downstream-initiated control
The second item to be discussed is whether the setup of a Dedicated-
VC and the control procedure for constructing a Bypass-pipe are
initiated by upstream side or downstream side.
In the case of the upstream-initiated control, the upstream node
takes the initiative when setting up a Dedicated-VC for a specific IP
flow and creating the mapping relationship between the IP flow and
the Dedicated-VC. For example, a CSR which detects datagrams for ftp
sets up (or fetches) a Dedicated-VC toward its downstream neighbor
and notifies its downstream neighbor that it will transmit a specific
IP flow over the Dedicated-VC. This means that the downstream node
is requested to receive datagrams from the Dedicated-VC.
In the case of the downstream-initiated control, the downstream node
takes the initiative when setting up a Dedicated-VC for a specific IP
flow and creating the mapping relationship between the IP flow and
the Dedicated-VC. For example, a CSR which detects datagrams for ftp
sets up (or fetches) a Dedicated-VC toward its upstream neighbor and
requests its upstream neighbor to transmit a specific IP flow over
the Dedicated-VC. This means that the upstream node is requested to
transmit the IP flow over the Dedicated-VC.
c) Hard-state management vs. Soft-state management
The third item to be discussed is whether the control (setup,
maintain, and release) of the Bypass-pipe is based on hard-state or
soft-state.
In hard-state management, individual nodes transmit Bypass-pipe
control messages only when they want to notify or request any change
in their neighbors' state. They should wait for an acknowledgement
of the message before they change their internal state. For example,
after setting up a Bypass-pipe, it is maintained until either of a
peer nodes transmits a message to release the Bypass-pipe.
In soft-state management, individual nodes periodically transmit
Bypass-pipe control messages in order to maintain their neighbors'
state. They do not have to wait for an acknowledgement of the
message before they changes its internal state. For example, even
after setting up a Bypass-pipe, either of a peer nodes is required to
periodically transmit refresh messages to its neighbor in order to
maintain the Bypass-pipe.
5. Security Considerations
Security issues are not discussed in this memo.
Katsube, et. al. Informational [Page 16]
RFC 2098 Toshiba's Router Extension for ATM February 1997
6. Summary
Basic concept of Cell Switch Router (CSR) are clarified and control
architecture for CSR is discussed. A number of methods to control
Bypass-pipe will be possible each of which has its own advantages and
disadvantages. Further investigation and discussion will be
necessary to design control protocol which may depend on the
requirements by users.
7. References
[IPMC96] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based
ATM Networks", RFC 2022, November 1996.
[ATM3.1] The ATM-Forum, "ATM User-Network Interface Specification,
v.3.1", Sept. 1994.
[RSVP13] Braden, R., et al., "Resource ReSerVation Protocol (RSVP),
Version 1 Functional Specification", Work in Progress.
[IPNNI96] R. Callon, et al., "Issues and Approaches for Integrated
PNNI", The ATM Forum Contribution No. 96-0355, April 1996.
[NHRP09] Luciani, J., et al., "NBMA Next Hop Resolution Protocol
(NHRP)", Work in Progress.
[PNNI1.0] The ATM-Forum, "P-NNI Specification Version 1.0", March
1996.
[RFC1483] Heinanen, J., "Multiprotocol Encapsulation over ATM
Adaptation Layer 5", RFC 1483, July 1993.
[RFC1577] Laubach, M., "Classical IP and ARP over ATM", RFC 1577,
October 1993.
[RFC1819] Delgrossi, L, and L. Berger, "Internet STream Protocol
Version 2 (STII) Protocol Specification Version ST2+", RFC 1819,
August 1995.
Katsube, et. al. Informational [Page 17]
RFC 2098 Toshiba's Router Extension for ATM February 1997
8. Authors' Addresses
Yasuhiro Katsube
R&D Center, Toshiba
1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
Japan
Phone : +81-44-549-2238
EMail : katsube@isl.rdc.toshiba.co.jp
Ken-ichi Nagami
R&D Center, Toshiba
1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
Japan
Phone : +81-44-549-2238
EMail : nagami@isl.rdc.toshiba.co.jp
Hiroshi Esaki
R&D Center, Toshiba
1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
Japan
Phone : +81-44-549-2238
EMail : hiroshi@isl.rdc.toshiba.co.jp
Katsube, et. al. Informational [Page 18]
|