Network Working Group                                   Noritoshi Demizu
Internet Draft                                                   SonyCSL
Expiration Date: February 1998                               August 1997


              VC pool and ATM SVC support for ATM-LSRs

                     <draft-demizu-vcpool-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),
     ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim),
     ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).


Abstract

Several label switching schemes are proposed to fuse and integrate
Layer 2 and Layer 3.  ATM-LSR is one of the major applications of
label switching.

Certain types of Virtual Connections (VCs) including ATM SVC require
signaling to establish VCs before employing them and to release VCs
after utilizing them.  Because signaling may introduce delays and
costs, some kind of optimization is important.

This document proposes to introduce a VC pool to reduce the delays and
the costs of signaling.  This document also proposes procedures to
deal with ATM SVCs between LSRs.


1. Introduction

Several label switching schemes[ARIS][RFC2098][RFC2105][RFC1953] are
proposed to fuse and integrate the cost-performance and QoS assurance
of devices of Layer 2 and the flexibility and functionality protocols
of Layer 3.

Those label switching schemes can be applied to various datalinks.
ATM-LSR is one of the major applications of label switching.  ATM has
two types of Virtual Connections (VCs) from the point of view of
dependency to signaling; Permanent VC (PVC) and Switched VC (SVC).

Certain types of VCs including ATM SVC require signaling to establish
VCs before employing them and to release VCs after utilizing them.
Because signaling may take long time and carriers may charge each
signaling, connecting time and/or the amount of traffic, some kind of
optimization is important to reduce the delays and the costs of such
signaling.

This document proposes to introduce a VC pool to reduce them.  This
document also proposes procedures to deal with ATM SVCs between LSRs.


2. Proposal of VC pool

2.1 VC pool

A VC pool is a pool where a number of VCs are prepared.  VCs can be
picked from the VC pool on BIND procedures immediately and will be put
back to the VC pool on UNBIND procedures.  Those VCs can be recycled
without unnecessary signaling.  If there are too many VCs in a VC
pool, some of them may be released to reduce the costs to keep VCs.
It becomes easy to use both directions of VCs with a VC pool.

Each established VC in a VC pool is associated with a VC-ID[VCID],
because it is sometimes impossible to use datalink specific
information as an identifier of a VC in a VC pool due to its small
range.  For example, the BLLI of the ATM Forum Signaling cannot be
used to distinguish more than 128 VCs.  However, the association
between a VC and a VC-ID can be postponed until the VC will be used if
protocol optimization is necessary.  Another benefit of VC pool is
that it hides the details of signaling procedures of each datalink
from label distribution protocols.

An LSR may have multiple VC pools for each VC class.  The examples of
VC classes here are UBR VCs, CBR VCs, point-to-multipoint VCs, etc.

Note that the idea of VC pool does not conflict with current potential
implementations, because they can be considered as subsets of VC pool,
where all VCs are prepared apriori and there is no way to establish
VCs nor to release VCs.  Also note that VC pool can be applied to
other datalinks than ATM.


2.2  Parameters of VC pool

A VC pool has following parameters:

   Low water mark:
	- It is required to prepare at least this number of VCs in the
	  VC pool.
   High water mark:
	- It is required to release VCs, if the number of VCs in the
	  pool exceeds this number under the constraint of the hold
	  time parameter.
   Hold time:
	- It is required to wait for at least hold time seconds before
	  releasing VCs after its use.  Releasing can be postponed
	  until just before next charging time.
   Limit:
	- The total number of established VCs, including both those in
	  the VC pool and those in use, must not exceed this number.
   Array of the pair of Min and Max:
	- The range of VC-ID is the union of the ranges specified by
	  each Min and Max pair.


2.3  Examples of parameters

Parameters of a VC pool should be carefully chosen to reduce delays
and costs case by case, by considering various characteristics of
datalinks, binding schemes, tariff, etc.  Here are the examples of
parameters chosen for the following cases.  The values bellow are only
for examples.

   Case 1: In the case of ATM SVC with a traffic-driven scheme:
	- All VCs are UBR
	- Low_water = 5, High_water = 20, Hold_time = several seconds
	- Min, Max, Limit are given
	(Effective if signaling takes long time or signaling is expensive)

   Case 2: In the case of ATM SVC with a topology-driven scheme:
	- All VCs are UBR
	- Low_water = 0, High_water = 0,  Hold_time = few seconds
	- Min, Max, Limit are given.
	(Effective if signaling takes long time or signaling is
	 expensive, especially when route changes)

   Case 3: In the case where it is difficult to recycle VCs, for instance,
	   VCs with reserved resources or point-to-multipoint VCs:
	- Low_water = 0, High_water = 0,  Hold_time = several seconds
	- Min, Max, Limit are given

   Case 4: In the case of ATM VP or PVC:
	- Low_water = High_water = Limit = the number of available VCs
	- Hold_time = 0
	- Min, Max are given.
	(VC pool need not be implemented for this case.)

Note that the case 4 represents the current potential implementations.


3. ATM SVC

3.1 ATM Forum Signaling

The ATM Forum defines a signaling protocol to set up SVCs.  In this
document, it is called as "ATM Forum Signaling".

Callers can transfer out-of-band information to callees by the ATM
Forum Signaling.  BLLI is one of information that must be transferred
and is user specific 7 bit field in L3 protocol field in BLLI IE
(Broadband Low Layer Information, Information Element).  When a new VC
is established by the ATM Forum Signaling, the callee can read the
BLLI value and caller's ATM address of the VC.

In the proposal of this document, BLLI value is used as a temporary
identifier of a VC, and its lifetime is limited to the VC-ID
negotiation period of the VC between a caller LSR and a callee LSR.
So the BLLI value of the new VC should not be assigned for other VCs
to avoid conflicts until a VC-ID is associated with the new VC.  And
after the association of the BLLI to the VC-ID has been completed, the
BLLI value of the new VC can be assigned to other VCs.  VC-ID values
can be assigned independently from BLLI values.

A point-to-multipoint VC can also be established by using ADD_PARTY of
the ATM Forum Signaling.  ADD_PARTY adds a new VC leaf to an existing
VC or an existing VC tree and makes a point-to-multipoint VC tree as a
result.  In this procedure, the BLLI value of ADD_PARTY should be the
same value as that was used to establish the first point-to-point VC
of the tree.  However, different VC trees can use the same BLLI value
without any conflicts between them.  So the BLLI value of each
signaling should be determined by the root node of the existing tree
for consistency.

There can be another method to exchange identity information of VCs
between negotiating LSRs.  For example, a caller can send an in-band
control message to a callee over the established new VC in order to
notify the identity information of the VC.  This method works well in
unicast case, but causes a problem in multicast.  The caller need
temporarily unsplice the active VC each time a new leaf LSR joins the
multicast tree in order to send such in-band messages to the leaf.
This will cause serious degradation in the performance at the LSR.
Otherwise, we should mandate mon-interleaving switching fabric for the
LSR.  So this document does not employ this method.

The remaining part of this section describes procedures to
negotiate a VC-ID between a caller and a callee.  The detailed
procedures should be defined in each label distribution protocol.  How
to get the ATM address of a callee at a caller is out of scope of this
document.


3.2 Support for unicast traffic

This section proposes procedures to establish a VC and to negotiate
its VC-ID for unicast traffic.

In the case where an upstream LSR allocates a VC-ID for a new VC, this
document proposes following procedures.

	0. In the case where a downstream LSR starts to prepare a VC in
	   a VC pool, the downstream LSR sends a VC establishment
	   request message to its upstream LSR.  Otherwise, skip step 0.

	1. An upstream LSR performs an ATM Forum Signaling to
	   establish a VC between the downstream LSR with unique BLLI
	   value at this moment.
	   (If the association between the VC and a VC-ID should be
	    postponed until the VC starts to be used, resume here.)
	2. The upstream LSR notifies a pair of the BLLI value and a
	   VC-ID to the downstream LSR by using a message dedicated
	   for this purpose or together within a BIND message.
	3. The downstream LSR associates the VC of the BLLI value with
	   the VC-ID, and sends an ACK message to the upstream LSR.
	   If the VC-ID is used by some other VC, discard the old VC.
	4. After the upstream LSR receives the ACK message,
	   it assotiates the VC with the VC-ID. The VC is ready to be
	   used at this step, and the BLLI value that was allocated to
	   the VC is able to be re-used for other VC at this step.

In the case where a downstream LSR allocates a VC-ID for a new VC,
this document proposes following procedures.

	0. In the case where a downstream LSR starts to prepare a VC in
	   a VC pool, the downstream LSR sends a VC establishment
	   request message to its upstream LSR.  Otherwise, skip step 0.

	1. An upstream LSR performs an ATM Forum Signaling to
	   establish a VC between the downstream LSR with unique BLLI
	   value at this moment.
	   (If the association between the VC and a VC-ID should be
	    postponed until the VC starts to be used, resume here.)
	2. The downstream LSR notifies a pair of the BLLI value and a
	   VC-ID to the upstream LSR by using a message dedicated for
	   this purpose or together within a BIND message.
	3. The upstream LSR associates the VC of the BLLI value with
	   the VC-ID, and sends an ACK message to the downstream LSR.
	   If the VC-ID is used by some other VC, discard the old VC.
	4. After the downstream LSR receives the ACK message,
	   it associates the VC with the VC-ID. The VC is ready to be
	   used at this step, and the BLLI value that was allocated to
	   the VC is able to be re-used for other VC at this step.


3.3 Support for multicast traffic

This section proposes procedures to establish the first VC for
a multicast stream and to add a new VC leaf to an existing VC tree
including the negotiation of its VC-ID for a multicast stream by using
point-to-multipoint VCs.

In this proposal, An upstream LSR determines both VC-ID and BLLI
value.  The reason BLLI value is determined by an upstream LSR is
described in section 3.1.  Since it is hard to recycle
point-to-multipoint VCs, VC pool would not be used for multicast.

This document proposes following procedure for the first VC.

	1. An upstream LSR performs an ATM Forum Signaling to
	   establish a VC between its downstream LSR with unique
	   BLLI value at this moment.
	2. The upstream LSR notifies a pair of the BLLI value and a
	   VC-ID to the downstream LSR by using a message dedicated
	   for this purpose or together within a BIND message.
	3. The downstream LSR associates the VC of the BLLI value with
	   the VC-ID, and sends an ACK message to the upstream LSR.
	   If the VC-ID is used by some other VC, discard the old VC.
	4. After the upstream LSR receives the ACK message, the VC is
	   ready to be used and the BLLI value can be used for other VC.

This document proposes following procedures for the second VC or later.

	1. The upstream LSR performs an ATM Forum Signaling to
	   establish a VC between its downstream LSR with the BLLI
	   value that was used for the first signaling.
	   In the case where another VC is using the BLLI value for
	   its signaling just the same time, wait for the completion
	   of the signaling procedure.
	2. Goto step 2 of the procedure for the first VC.


Security Considerations

Security issues are not discussed in this document.


Acknowledgments

The author would like to acknowledge valuable technical comments
from members of LAST-WG of WIDE Project, in particular from
Kenichi Nagami, Hiroshi Esaki and Yasuhiro Katsube.  The author
also would like to acknowledge Paul Doolan.


References

[ARIS]	A. Viswanathan, et. al.,
	"ARIS: Aggregate Route-Based IP Switching",
	draft-viswanathan-aris-overview-00.txt, Mar 1997
[RFC2098] Y. Katsube, et. al.,
	"Toshiba's Router Architecture Extensions for ATM : Overview",
	RFC2098, Feb 1997
[RFC2105] Y. Rekhter, et. al.,
	 "Cisco Systems' Tag Switching Architecture Overview",
	RFC2105, Feb 1997
[RFC1953] P. W. Edwards, et. al.,
	"Ipsilon Flow Management Protocol Specification for IPv4 Version 1.0",
	RFC1953, May 1996
[ATM_SVC] H. Esaki, et. al.,
       "IP Address Resolution and ATM Signaling for MPLS over ATM SVC services"
	draft-katsube-mpls-over-svc-00.txt, Jun 1997
[TAG_ATM] B. Davie, et. al.,
	"Use of Tag Switching With ATM"
	draft-davie-tag-switching-atm-01.txt, Jan 1997
[PLASMA] K. Fujikawa,
	"Point-to-point Link Assembly for Simple Multiple Access (PLASMA)",
	draft-fujikawa-plasma-00.txt, Mar 1997
[RFC2129] K. Nagami, et. al.,
	"Toshiba's Flow Attribute Notification Protocol (FANP) Specification",
	RFC2129, Apr 1997
[TDP]	P. Doolan et. al.,
	"Tag Distribution Protocol",
	draft-doolan-tdp-spec-01.txt, May 1997
[ARISP]	N. Feldman, A. Viswanathan,
	"ARIS Specification",
	draft-feldman-aris-spec-00.txt, Mar 1997
[VCID] N. Demizu,
	"VC-ID",
	draft-demizu-vcid-00.txt, Aug 1997

Author Information

	Noritoshi Demizu
	Sony Computer Science Laboratory, Inc.
	Takanawa Muse Bldg.
	3-14-13, Higashigotanda,
	Shinagawa-ku, Tokyo, 141 Japan
	Phone: +81-3-5448-4380
	E-mail: demizu@csl.sony.co.jp