Internet DRAFT - draft-esaki-mpls-over-svc
draft-esaki-mpls-over-svc
HTTP/1.1 200 OK
Date: Mon, 08 Apr 2002 23:49:37 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Fri, 28 Mar 1997 12:02:50 GMT
ETag: "2e69e5-36fc-333bb36a"
Accept-Ranges: bytes
Content-Length: 14076
Connection: close
Content-Type: text/plain
Internet Draft March 1997
H. Esaki (Toshiba Corp.)
Y. Katsube (Toshiba Corp.)
K. Nagami (Toshiba Corp.)
P. Doolan (Cisco Systems Inc.)
Y. Rekhter (Cisco Systems Inc.)
IP Address Resolution and ATM Signaling for MPLS
over ATM SVC services
<draft-esaki-mpls-over-svc-00.txt>
Status of this memo
This document is an Internet-Draft. 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."
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
Enabling interconnection of ATM Label Switching Routers (ATM-LSRs)
over standard ATM switch networks is desirable in order to
introduce MPLS technology into emerging ATM-LAN/WAN platform.
This draft describes how ATM-LSRs may interoperate with other
ATM-LSRs over ATM UNI SVC services. The two aspects of the problem
that we address are ATM address (of target ATM-LSR) resolution and
SVC to label binding.
1. Introduction
Several architectural models for label switching are proposed to
the MPLS working group, e.g., [ARIS][RFC2098][RFC2105]. One of the
major application of MPLS technology described in these proposals
is ATM.
Esaki, et al. Expires Sept. 1997 [Page 1]
Internet Draft draft-esaki-mpls-over-svc-00.txt March 1997
Interconnecting ATM-LSRs over point-to-point links is straight-
forward since it is analogues to conventional ATM switch networks
except for the difference in the control protocol (ATM-UNI/NNI
control plane vs. MPLS specific control plane). It is possible to
build "Hybrid" ATM-LSRs that operate in a "Ships in the night" mode
running both MPLS and ATM Forum control planes on the same link
[ATM_TAG]. It is also possible to interconnect ATM-LSRs over a cloud
of standard ATM switches, which are non-MPLS ATM switches.
Interconnecting ATM-LSRs over a cloud of standard ATM switches using
VP services is described in [ATM_TAG]. In this case, the VCIs within
the VP are the labels, and again the MPLS control plane can manage
them similar to the point-to-point link case.
This document describes operations of MPLS over ATM SVC networks.
One possible circumstances where this might be necessary is ATM-LSRs
interconnected through ATM switches that support ATM SVC services
(e.g., ATM WAN cloud).
Imagine two LSRs connected via such an ATM cloud. If one LSR decides,
by normal L3 routing procedures, that it must forward traffic to the
other, it opens an ATM SVC to that LSR. The question is "how does it
obtain the ATM address of the target LSR to put in the SVC
Setup?". When we answer this question, another immediately occurs:
"when the SVC Setup arrives at the target LSR, how does that system
know to which route or Forwarding Equivalence Class(FEC)[TAG_ARCH]
this new SVC should be bound?".
The diagram below shows a more general view of the application
space.
We provide answers to these questions below in sections 2 and 3
respectively.
+---+ +---+ +---+
|LSR| +-----+ +-----+ |LSR| +-----+ +-----+ |LSR|
-| |-|ATMSW|-...-|ATMSW|-| |-|ATMSW|-...-|ATMSW|-| |-
+---+ +-----+ +-----+ +---+ +-----+ +-----+ +---+
<---------------------> <------------------->
standard ATM link standard ATM link
<=========================================================>
ATM cloud (or collections of ATM clouds)
Fig.1 Label Switching Routers (LSRs) with standard ATM links
Esaki, et al. Expires Sept. 1997 [Page 2]
Internet Draft draft-esaki-mpls-over-svc-00.txt March 1997
2 LSR ATM address selection
An ATM-LSR, having made a determination that it must route traffic
to another ATM-LSR, and finding, through some local procedure, that
it must open an ATM SVC to that ATM-LSR must select an appropriate
ATM address to place in the SVC Setup message.
The selection of the address may be based on configuration or on
dynamic resolution. In either case the ATM-LSR has, from its routing
table, an IP address for which it requires a corresponding ATM
address.
2.1 Configuration
It is possible to provide tools and procedures to configure an ATM-
LSR with, for example, IP to ATM address translation tables. The
control mechanisms in the LSR that are responsible for deciding to
setup SVCs could use these tables to obtain requisite ATM address
for peer ATM-LSRs.
This operation could be seen as the existing point-to-point link
operation over SONET links, and it may become common for LSRs over
WAN ATM links.
2.2 Dynamic resolution
2.2.1 Classical IP over ATM LSRs
If the ATM-LSR is configured to be able to reach an RFC1577 ARP
server and if the IP address of the target LSR is on the same subnet
then the LSR may employ ATM-ARP [RFC1577] to attempt to resolve the
ATM address of the target ATM-LSR.
2.2.2 NHRP capable LSRs
If the ATM-LSR is able to reach an NHRP server, by configuration,
anycast or MPOA LE_ARP discovery [MPOA], then it may use NHRP to
attempt to resolve the ATM address of the target ATM-LSR.
3 Binding of ATM SVCs and MPLS labels
When an ATM-LSR has decided to open an SVC to its neighbor ATM-LSR
and has determined the appropriate ATM address using the procedures
in section 2, it uses the mechanisms described here to communicate
the 'binding' between the SVC and specific forwarding equivalence
class(FEC)[TAG_ARCH]. The MPLS label value, which is VPI/VCI or VCI
Esaki, et al. Expires Sept. 1997 [Page 3]
Internet Draft draft-esaki-mpls-over-svc-00.txt March 1997
in ATM, is not the same at both ends of an SVC. Therefore,
neighboring ATM-LSRs, when they are communicating with each other,
cannot use the label as an identifier of the SVC but should use
another identifier that can be uniquely identified by both ends of
the SVC. The binding between the unique identifier and the label
is performed locally at individual ATM-LSRs.
Basic mechanism of binding for SVC is to convey a unique identifier
of an SVC in the BLLI IE of SETUP message, and to convey the
identifier of the SVC in the MPLS binding request and/or
acknowledge messages together with the specific FEC. Some example
procedures are described below.
3.1 Support for Destination-based unicast routing over ATM SVCs
Following the procedures outlined in [TAG_ATM], an ATM-LSR sends
an MPLS message that request binding to its next-hop (downstream)
ATM-LSR for the destination prefix contained in the request.
The downstream ATM-LSR that receives the request provides
a binding that contains an identifier that is unique between the
upstream ATM-LSR. The upstream ATM-LSR, after it receives the
binding sets up an SVC to the downstream ATM-LSR using the ATM
Forum signalling procedures, which includes the received identifier
in the BLLI field of the Setup message. The downstream LSR
accepting the SVC setup is able to determine, from the identifier
value in BLLI, the binding of this new SVC to the destination
prefix.
Another examples would be possible, e.g., SVC setup including
unique identifier in the BLLI field may proceed the MPLS messages
that exchange binding between the SVC (identified by the value at
BLLI field) and the destination prefix.
Whether the 7-bit BLLI space for the identifier is enough or not
depends on up to when the identifier value should be held for a
certain SVC, which further depends on the protocol to maintain or
remove binding. For instance, if the removal of binding is
performed by releasing the related SVC with a RELEASE message of
ATM signaling, the unique identifier should be maintained only for
the period between the time when the binding procedure begins and
the binding has been established.
3.2 Support for multicast over ATM SVCs
In the case that PIM-SM is used as a multicast routing protocol,
following the procedures outlined in [TAG_PIM], an ATM-LSR sends
PIM_Join messages to upstream neighboring ATM-LSRs toward the RP
Esaki, et al. Expires Sept. 1997 [Page 4]
Internet Draft draft-esaki-mpls-over-svc-00.txt March 1997
for the shared-tree (*,G) or source for the source-tree (S,G).
If the two ATM-LSRs are using SVC, the downstream LSR will include
a unique identifier for an SVC, instead of label value, in the PIM
Join message. When the upstream router receives the PIM Join, it
will set up, using ATM signalling procedures, an SVC to the
downstream ATM-LSR. The Upstream router sends the identifier it
received in the PIM Join message in the BLLI IE of the SETUP
message that it uses to establish the SVC. In this way the
downstream ATM-LSR is able to associate the new SVC's label with
the appropriate multicast tree. Once an SVC is setup for a group,
subsequent PIM Join (refreshes) include the value zero in the
identifier field. This special value indicates to the next hop
router toward the RP that a SVC already exists and in this case
that router simply refreshes its PIM state without initiating SVC
setup.
The identifier employed for this purpose is constrained by the
available space in the BLLI to be 7 bits also. Whether this small
space is enough or not depends on up to when the identifier value
should be held for a certain SVC, which further depends on the
protocol to maintain or remove binding. For instance, if the
identifier is only of significance to the downstream LSR and only
significant to it during the period between the dispatch of the
PIM Join to the upstream router and the completion of the SVC
setup, this is not a major restriction.
Another examples, e.g., a multicast routing protocol other than
PIM-SM is used, would be possible and added in later version of
the draft.
4. Security Consideration
Security considerations are not addressed in this memo.
5. References
[ARIS] R.Woundy, A.Wiswanathan, N.Feldman, R.Biovie, "ARIS:
Aggregated Route-Based IP Switching",
draft-woundy-aris-ipswitching-00.txt, November, 1996.
[FANP] K.Nagami, Y.Katsube, Y.Shobatake, A.Mogi, S.Matsuzawa,
T.Jinmei, H.Esaki, "Flow Attribute Notification Protocol
(FANP) Specification",
draft-rfced-info-fanp-00.txt, December, 1996.
[LANE] ATM Forum, "LAN Emulation over ATM Specification Ver.1.0",
April, 1995.
[MPOA] ATM Forum, "Multi Protocol Over ATM" (Work in Progress)
Esaki, et al. Expires Sept. 1997 [Page 5]
Internet Draft draft-esaki-mpls-over-svc-00.txt March 1997
[NHRP] J.V.Luciani, D.Katz, D.Piscitello, B.Cole,
"NBMA Next Hop Resolution Protocol (NHRP)",
draft-ietf-rolc-nhrp-10.txt, October, 1996.
[RFC1577] M.Laubach, "Classical IP and ARP over ATM",
IETF RFC1577, October, 1993.
[RFC1953] P.Newman, et al, "Ipsilon Flow Management Protocol
Specification for IPv4 version 1.0", IETF RFC1953,
May, 1996.
[RFC2098] Y.Katsube, K.Nagami, H.Esaki, "Toshiba's Router
Extensions for ATM", IETF RFC2098, February, 1997.
[RFC2105] Y.Rekhter, B.Davie, D.Katz, E.Rosen, G.Swallow,
"Cisco System's Tag Switching Overview", IETF RFC2105,
February, 1997.
[TAG_ARCH] Y. Rekhter, B. Davie, D. Katz, E. Rosen, G. Swallow,
D. Farinacci, "Tag Switching Architecture - Overview",
draft-rekhter-tagswitch-arch-00.txt, Jan. 1997.
[TAG_ATM] B Davie, P Doolan, J Lawrence, K McCloghrie, Yakov Rekhter,
E Rosen, G Swallow, "Use of Tag Switching with ATM",
draft-davie-tag-switching-atm-01.txt, Jan. 1997.
[TAG_PIM] D. Farinacci, Y. Rekhter, "Multicast Tag Binding and
Distribution using PIM", draft-farinacci-multicast-tagsw-
00.txt, Dec. 1996.
[TDP] P.Doolan, B.Davie, D.Katz, Y.Rekhter, E.Rosen,
"Tag Distribution Protocol",
draft-doolan-tdp-spec-00.txt, September, 1996.
6. Authors
Hiroshi Esaki
Computer and Network Division,
Toshiba Corporation,
1-1-1 Shibaura,
Minato-ku, 105-01, Japan.
Email: hiroshi@isl.rdc.toshiba.co.jp
Yasuhiro Katsube
R&D Center, Toshiba Corporation,
1 Komukai-Toshiba-cho, Saiwai-ku,
Kawasaki, 210, Japan
Email: katsube@isl.rdc.toshiba.co.jp
Ken-ichi Nagami
R&D Center, Toshiba Corporation,
1 Komukai-Toshiba-cho, Saiwai-ku,
Kawasaki, 210, Japan
Email: nagami@isl.rdc.toshiba.co.jp
Esaki, et al. Expires Sept. 1997 [Page 6]
Internet Draft draft-esaki-mpls-over-svc-00.txt March 1997
Paul Doolan
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA, 01824
Email: pdoolan@cisco.com
Yakov Rekhter
Cisco Systems, Inc.
170 Tasman Drive
San Jose, CA, 95134
Email: yakov@cisco.com
Esaki, et al. Expires Sept. 1997 [Page 7]
