Internet DRAFT - draft-imajuku-ccamp-gmpls-vcat-lagr-req
draft-imajuku-ccamp-gmpls-vcat-lagr-req
CCAMP Working Group W. Imajuku
Internet-Draft Y. Tsukishima
Expires: January 2006 NTT
Y. H. Kim
ETRI
June 11, 2005
GMPLS extension requirements
for virtual concatenation and link aggregation control
<draft-imajuku-ccamp-gmpls-vcat-lagr-req-00.txt>
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are 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 a "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.
This Internet-Draft will expire on January 11, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
This draft describes requirements of GMPLS extension to be supported
in dynamic or static inter-working Generalized Multi-protocol Label
Switching (GMPLS) protocol and multi-link technologies such as
virtual concatenation (VCAT), link capacity adjustment scheme (LCAS)
and link aggregation (LAGR).
Conventions used in this document
In this document the steps for walking a pull-down tree are indented
on subsequent lines. This allows abbreviation rather than a barrage
of 'then click' or 'select' strings in a paragraph form. Example:
Imajuku, Tsukishima and Kim Expires - January 2006 1
draft-imajuku-ccamp-gmpls-vcat&lagr-req-00.txt June 2005
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
Table of Contents
Abstract
1. Introduction...................................................1
2. Need for VCAT & LCAS and LAGR & LACP Control Support in GMPLS..2
3. Problem Statement..............................................6
4. Requirements for GMPLS Extension...............................6
5. FA Considerations..............................................7
6. Security Considerations........................................9
7. IANA Considerations............................................9
8. Normative References...........................................9
9. Informative References........................................10
Author's Addresses...............................................10
Intellectual Property Statement..................................11
1. Introduction
The Generalized Multi-Protocol Label Switching (GMPLS) control plane
has been expected to unify the control scheme of networks with
multiple switching capabilities and achieve fast provisioning and
dynamic control of Label Switched Paths (LSPs). Dynamic LSP control
includes not only protection and restoration, but also capacity
control of the LSPs. As for the capacity control of the LSPs, fast
control of the LSP capacity can enhance the degree of resiliency
against unexpected traffic surges, which can be caused by a Label
Switch Router (LSR) failure and so on, and enhance the capacity
control of a higher order LSP such as the SDH/SONET from a lower-
order LSP such as the Ethernet LSP.
The combined usage of virtual concatenation (VCAT) [ITU-T G.707-SDH],
[ITU-T G.707-SONET] and the link capacity adjustment scheme (LCAS)
[ITU-T G.7042] provides dynamic capacity control of the LSP in the
SDH/SONET network. The LCAS achieves hitless bandwidth modification
via signaling in the H4 byte of the SDH/SONET link (Here, "hitless"
means no packet loss). Analogous to the VCAT & LCAS in the SDH/SONET
link, link aggregation (LAGR) and the link aggregation control
protocol (LACP) [IEEE 802.3ad] can be applied to the capacity
control of LSPs. Although the capacity for each packet flow cannot
exceed the capacity of the component links, by using LAGR the total
capacity of the LSP can exceed the limit of the interface speed.
Typically, network management systems (NMSs) are required to manage
the physical structure, i.e. bay, shelf, and slot, of each network
Imajuku, Tsukishima and Kim Expires - January 2006 2
draft-imajuku-ccamp-gmpls-vcat&lagr-req-00.txt June 2005
element (NE) to set the VCAT group or the LAGR group at each LSP
termination point. The VCAT and LAGR technologies require manual
setting to form the group LSP at both LSP termination points. This
can be an obstacle in achieving autonomous control of the LSP
capacity.
This document describes the requirements for GMPLS support of VCAT &
LCAS and LAGR & LACP control. First, this document clarifies the
problems in applying GMPLS to the VCAT & LCAS and LAGR & LACP
control. Then, this document describes the GMPLS extension
requirements and considers the VCAT group and the LAGR group as
forwarding adjacency (FA). The following abbreviations are used in
this document:
FA: Forwarding Adjacency
GFP: Generic Framing Procedure
GMPLS: Generalized Multi-Protocol Switching
LACP: Link Aggregation Control Protocol
LAGR: Link Aggregation
LCAS: Link Capacity Adjustment Scheme
LSP: Label Switched Path
LSR: Label Switch Router
PSC: Packet Switch Capable
SDH: Synchronous digital hierarchy
SONET: Synchronous optical network
STS-N: Synchronous Transport Signal-Level N (SONET)
VC: Virtual Container
VC-n: Virtual Container-n (SDH)
VCAT: Virtual Concatenation
2. Need for VCAT & LCAS and LAGR & LACP Control Support in GMPLS
This section describes the need for GMPLS functionality to control
VCAT & LCAS and LAGR & LACP. Figure 1 shows the assumed GMPLS
network comprising the SDH/SONET switch capable nodes achieving
STS-3n/VC-n LSP cross-connection and packet switch capable (PSC)
nodes. The links amongst SDH/SONET nodes are SDH/SONET links.
All of the PSC nodes are accommodated by the SDH/SONET nodes via
multiple Ethernet links.
The SDH/SONET nodes of T1, T3, and T4 in the SDH/SONET region have
the Generic Framing Procedure (GFP), VCAT, and LCAS capabilities. In
other words, these nodes cannot only terminate multiple component
VC-n LSPs to form a VC-n LSP group, i.e., virtually concatenated
VC-n-xv LSP, with the VCAT functionality, but also "hitlessly"
change the component VC-n LSPs in the VC-n LSP group with the LCAS
functionality. Therefore, these nodes can provide a "flexible
bandwidth" to their clients.
Imajuku, Tsukishima and Kim Expires - January 2006 3
draft-imajuku-ccamp-gmpls-vcat&lagr-req-00.txt June 2005
The PSC nodes P1, P2, and P3 have the LAGR and LACP capabilities.
Therefore, P1, P2, and P3 can establish an Ether-LSP with multi
-link capacity. When the PSC nodes establish the LAGR group LSPs,
the PSC nodes start to exchange LACP packets in the LSP. In this
document, we call this LSP the LAGR group LSP. Although the capacity
for each packet flow cannot exceed the capacity of the component
LSPs, by using LAGR the total capacity of the LAGR group LSP can
exceed the limit of the interface speed.
PSC region #A | SDH/SONET region | PSC region #B
| |
+------+ GbE x2 +---------+ +---------+ |
|P1,PSC|----------|T1,TDM-SC|-------|T2,TDM-SC| |
| |----------|VCAT&LCAS| | | |
+------+ | +---------+ +---------+ |
| | | |
| | | |
| | | |
| | | |
+------+ GbE x2 +---------+ +---------+ GbE x2 +------+
|P2,PSC|----------|T3,TDM-SC|-------|T4,TDM-SC|----------|P3,PSC|
| |----------|VCAT&LCAS| |VCAT&LCAS|----------| |
+------+ | +---------+ +---------+ | +------+
Figure 1: SDH/SONET-SC and PSC interoperable network
2.1 Need for VCAT & LCAS control
The creation and deletion of virtually concatenated LSPs such as
VC-n-xv LSP are achieved under GMPLS control. GMPLS signaling can
perform not only direct creation and deletion of a VC-n-xv LSP, but
also the step-by-step creation and deletion of its component VC-n
LSP to form the VC-n-xv LSP.
The route of the component VC-n LSPs of the VC-n-xv LSP may be unique
or node diverse. For example, the LSP group, i.e. the VC-4-7v LSP,
between T1 and T4 may comprise seven component VC-4 LSPs with the
route of T1, T2, and T4. In this case, the "bandwidth modification"
of the VC-4-xv LSP may be achieved by modifying SUKLM LABEL and
SDH/SONET SENDER TSPEC [RFC 3946] of the VC-4-xc LSP. Alternatively,
the VC-4-7v LSP may comprise four component VC-4 LSPs with the route
of T1, T2, and T4, and three component VC-4 LSPs with the route of
T1, T3, and T4. The SDH/SONET nodes with the VCAT functionality
absorb the differential delay amongst the component VC-4 LSPs. In
this case, the "bandwidth modification" of the LSP group, i.e. the
VC-4-7v LSP, is achieved by the "connection association
modification" of the component VC-4 LSPs. The GMPLS signaling should
include the group ID information clarifying to which VC-4-7v LSP the
component VC-4 LSP belongs.
Imajuku, Tsukishima and Kim Expires - January 2006 4
draft-imajuku-ccamp-gmpls-vcat&lagr-req-00.txt June 2005
The LCAS signaling is utilized to reconfigure the VC-n-xv LSP without
the loss of the client signal. The control packets of the LCAS
signaling are proactively sent to inform the receiver of the changes
in status at the transmitter using the H4 bite of the SDH/SONET
superframe and to achieve dynamic reconfiguration of the LSP group.
The control of the LCAS signaling is uni-directional. Therefore,
both termination nodes of the VC-n-xv LSP should initiate the LCAS
signaling by inter-working with the GMPLS signaling [GMPLS-LCAS].
The GMPLS signaling should be interoperable with LCAS signaling for
both the "bandwidth modification" and the "connection association
modification" cases. The success or failure of the LCAS signaling to
add or delete the VC-n bandwidth should be reflected on the GMPLS
control plane. This is especially important considering the "make-
before-break" procedure [RFC3209]. Consider the case of "bandwidth
modification" by creating a new session of the VC-n-xv LSP, the
ingress node should recognize whether all of the component VC-n LSPs
are successfully reconfigured to form a new VC-n-xv LSP. The ingress
node should initiate a "break" with the old signaling session after
that recognition.
2.2 The necessity of the LAGR&LACP control
The creation and deletion of the LAGR group LSP such as a multi-
gigabit Ether LSP can be achieved under GMPLS control. GMPLS
signaling can perform not only direct creation and deletion of the
LAGR group LSP, but also the step-by-step creation and deletion of
its component Ether LSPs to form the LAGR group LSP.
GMPLS signaling controls the "aggregators" at both LSP termination
points. The aggregators collect or distribute packets amongst
component LSPs so as to act as a single LSP for the client.
The LACP is utilized in the component LSPs in order to synchronize
the status of the "aggregator" at both LSP termination points.
Different from the LCAS signaling, LACP does not have the remote
control capability of a peer interface. The LACP simply provides
notifies the aggregator of the group ID information for the
component LSPs and other status information, which helps it to
determine whether or not to attach or detach component LSPs. GMPLS
signaling should include the group ID information to clarify to
which LAGR group LSP the component LSP belongs.
2.3 Need for VCAT&LCAS and LAGR&LACP control in hierarchical case
In a hierarchical network, the creation and deletion of the VC-n-xv
LSP between T1 and T4 may be initiated by the creation of an Ether
LSP between P1 and P4 with inter-domain TE signaling [INTER-DOMAIN-
RSVP-TE]. In such a case, "bandwidth modification" and "connection
Imajuku, Tsukishima and Kim Expires - January 2006 5
draft-imajuku-ccamp-gmpls-vcat&lagr-req-00.txt June 2005
association modification" of the VC-n-xv LSP between T1 and T4 may
be initiated by the signaling of the Ether LSP. The failure of the
LCAS signaling between T1 and T4 should result in the issuing of an
error notification from T1 to P1.
3. Problem Statement
3.1 Problem statement in routing aspect
One of the advantageous features of VCAT focuses on the
upgradeability from non-VCAT&LCAS nodes or networks. As shown in
Fig.1, T2 only provides the switching and termination capabilities
of VC-n LSP. In such a case, T1, T3, and T4 should confirm the VCAT
& LCAS capability when calculating the route and termination points
of the VC-n-xv LSPs. Therefore, each TDM node should advertise its
VCAT and LCAS capabilities.
Analogous to the VCAT & LCAS case, the PSC nodes should advertise
the LAGR capability, if they want to discrimate the LAGR capability.
3.2 Problem statement in signaling aspect
The LCAS signaling in the SDH/SONET data-plane is used for grouping
uni-directional virtual containers. Therefore, both the ingress and
egress nodes of the VC-n-xv LSP should initiate LCAS signaling as
described in the previous section. In order for the egress node to
set appropriately the component VC-n LSPs to form the VC-n-xv LSP,
GMPLS signaling should provide the capability to signal the group ID
for each component VC-n LSP.
The above problem statement can be commonly applied to the control of
the LAGR group LSPs. GMPLS signaling of component LSPs should include
the group ID in order for the egress PSC nodes to set the LAGR group
among Ethernet interfaces.
Also, the LCAS signaling in an upstream path of VC-n-xv LSP is
launched from the egress node. Therefore, the ingress node should
have the capability to control LCAS signaling of the bandwidth
modification or connection association modification from the egress
node. The explicit control and the confirmation of success in LCAS
signaling enhance the reliability of the "make-before-break"
procedure. In particular, the tearing down of the component VC-n
LSPs from the VC-n-xv LSP should be initiated after confirming
successful decomposition of the component VC-n LSPs.
4. Requirements for GMPLS Extension
The following extensions for the VCAT & LCAS and the LAGR & LACP
support are introduced in this document.
4.1 Extension for Routing Protocol
Imajuku, Tsukishima and Kim Expires - January 2006 6
draft-imajuku-ccamp-gmpls-vcat&lagr-req-00.txt June 2005
The ingress node should identify the VCAT, LCAS, or LAGR capability
of the egress node before the route calculation of the VC-n-xv LSP
or the LAGR LSP (group LSP). Every node having the VCAT, LCAS, and
LAGR capabilities are required to advertise the termination
capability considering a mixed environment of non-VCAT and LCAS
capable SDH/SONET nodes or non-LAGR PSC nodes. The VCAT and LCAS
capable SDH/SONET nodes are required to advertise the interface
switching capability descriptor [GMPLS-ROUTING] indicating VCAT
capable TDM or VCAT & LCAS capable TDM. Similarly, the LAGR
capable PSC nodes are required to advertise the interface switching
capability descriptor indicating LAGR capable PSC.
4.2 Extension for Signaling Protocol
4.2.1 Support for Group ID
The ingress node should include the group ID in the signaling of each
component LSP intending to participate in a certain group LSP. The
concepts of grouping and associating connections have been discussed
in relation to automatically switched optical network (ASON) support
[ASON-REQ] or protection and restoration support [E2E-RESTORATION],
respectively. Therefore, support for the group ID may not require a
new extension for signaling protocols rather the extension of
existing protocols.
This version of the document does not specify which objects should be
in use. However, the following notes should be taken into
consideration.
Note1: ASON requires call and connection separation. The Call ID, the
long format Call ID specified in [RFC3474] and short format Call ID
proposed in [ASON-RSVP-TE], can be used as the group ID of the group
LSP. The short format Call ID requires an extension in the SESSION
Object. Therefore, the usage of the short format Call ID should be
static. In other words, connection association modification cannot
be achieved by simply modifying the short format Call ID. The
connection association modification using the short format Call ID
shall be on the "make-before-break" basis only.
Note 2: Protection and restoration require that the ASSOCIATION
object be associated with working and back-up connections. In
addition, n back-up connections are associated to one working
connection. For the VCAT & LCAS or the LAGR & LACP control, all of
the n connections should be associated to one virtual connection,
i.e. the group ID.
4.2.2 Support for Explicit Control of LCAS Signaling
Imajuku, Tsukishima and Kim Expires - January 2006 7
draft-imajuku-ccamp-gmpls-vcat&lagr-req-00.txt June 2005
The ingress nodes should include L bits in the SDH/SONET SENDER
TSPEC object to initiate the LCAS signaling of the upstream path
from the egress node. In addition, the egress node should include
L bits in the SDH/SONET FLOWSPEC object as a successful response.
5. FA Considerations
This section considers the case in which the group LSP is used for FA
in the network.
5.1 Routing aspects
This section considers the case in which the group LSP is used for FA
in the network. The guideline for advertising the traffic
engineering extension of the FA-LSP is described in [HIERARCHY]. In
addition, the case in which FA is induced from the group LSP should
be considered analogous to link bundling [LINK-BUNDLING].
(1) Maximum Bandwidth [RFC3630]
This parameter is not used. The maximum LSP Bandwidth (as described
below) replaces the Maximum Bandwidth for the FA of the group LSP.
(2) Maximum LSP Bandwidth [GMPLS-ROUTING]
The Maximum LSP Bandwidth takes the place of the Maximum Bandwidth.
The Maximum LSP Bandwidth of the FA at priority p is defined to be
the maximum of the Maximum LSP Bandwidth at priority p of all
component LSPs.
(3) Max Reservable Bandwidth [RFC3630]
The FA advertisement of the group LSP is configured using the sum of
the Maximum Reservable Bandwidths of all component LSPs associated
with the group LSP or the FA advertisement of the group LSP is
configured with the Maximum Reservable Bandwidth of the component
LSPs. The case that should be employed may depend on the switching
capability of the network. However, the FA advertisement of the VC-
n-xv LSP in the PSC network may be the former case. On the other
hand, the FA advertisement of the link aggregation LSPs in the PSC
network may be the latter case.
(4) Link Protection Type [GMPLS-ROUTING]
The link protection type of the FA advertisement for the group LSP
should be unprotected unless all of the component LSPs are protected.
(5) Shared Risk Link Group (SRLG) [GMPLS-ROUTING]
SRLG of the FA advertisement for the group LSP should include all of
the SRLGs of the component LSPs.
5.2 Signaling aspects
Imajuku, Tsukishima and Kim Expires - January 2006 8
draft-imajuku-ccamp-gmpls-vcat&lagr-req-00.txt June 2005
If an LSR that originates a group LSP advertises this group LSP as an
unnumbered FA, or the LSR uses the FA formed by this LSP as an
unnumbered component LSP of a group LSP, the LSR MUST allocate an
identifier to that FA. Moreover, the Path message used for
establishing the LSP that forms the FA MUST contain the LSP
TUNNEL_INTERFACE_ID object as described in [RFC3477].
Whether or not the component LSP of the group LSP should set the same
LSP_TUNNEL_INTERFACE_ID depends on the policy of the LSRs at the
ingress and egress nodes of the group LSP. Discussion on this policy
is outside the scope of this document. However, the policy should be
consistent with the advertisement of the Max Reservable Bandwidth.
If the Max Reservable Bandwidth is the sum of the Maximum Reservable
Bandwidths of all component LSPs associated with the group LSP, the
component LSPs of the group LSP should be set to the same
LSP_TUNNEL_INTERFACE_ID. Otherwise, the component LSPs of the group
LSP should be set to a different LSP_TUNNEL_INTERFACE_ID.
6. Security consideration
Security consideration will be discussed in a future version. This
requirement will not change the underlying security issues.
7. IANA Considerations
This document does not contain any IANA actions.
8. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate
requirements levels", RFC 2119, March 1997.
[ITU-T G.707-SDH] International Telecommunications Union, "Network
node interface for the synchronous digital hierarchy (SDH)", ITU-T
Recommendation G.707, 2003.
[ITU-T G.707-SONET] American National Standards Institute,
"Synchronous Optical Network (SONET) - Basic Description including
Multiplex Structure, Rates, and Formats", 2001.
[ITU-T G.7042] International Telecommunications Union, "Link
Adjustment Scheme (LCAS) for virtual concatenated signals", ITU-T
Recomendation G.7042, 2004.
[IEEE802.3ad] "Information Technology I Local and Metropolitan Area
Networks I Part 3: Carrier Sense Multiple Access with Collision
Detection (CSMA/CD) Access Method and Physical Layer Specifications",
IEEE Standard 802.3, March 2002.
Imajuku, Tsukishima and Kim Expires - January 2006 9
draft-imajuku-ccamp-gmpls-vcat&lagr-req-00.txt June 2005
[RFC3946] "Generalized Multi-Protocol Label Switching (GMPLS)
Extensions for Synchronous Optical Network (SONET) and Synchronous
Digital Hierarchy (SDH) Control", RFC 3946, October 2004.
[RFC3209] Awduche D. et al., "RSVP-TE: Extensions to RSVP for LSP
Tunnels" RFC 3209, December 2001.
[INTER-DOMAIN-RSVP-TE] Ayyangar A. et al, "Inter domain MPLS Traffic
Engineering - RSVP-TE extensions", (work in progress).
[GMPLS-ROUTING] Kompella K. et al., "Routing Extensions in Support
of Generalized Multi-Protocol Label Switching", (work in progress).
[ASON-REQ] Papadimitriou D. et al, "Requirements for Generalized MPLS
(GMPLS) Signaling Usage and Extensions for Automatically Switched
Optical Network (ASON)", (work in progress).
[E2E-RESTORATION] Lang J. P. et al "RSVP-TE Extensions in
support of End-to-End Generalized Multi-Protocol Label Switching
(GMPLS)-based Recovery", (work in progress).
[RFC3474] Lin Z. and Pendarakis D., "Documentation of IANA
assignments for Generalized MultiProtocol Label Switching (GMPLS)
Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Usage
and Extensions for Automatically Switched Optical Network (ASON)" ,
(work in progress).
[ASON-RSVP-TE] Drake J. et al, "Generalized MPLS (GMPLS) RSVP-TE
Signaling in support of Automatically Switched Optical Network
(ASON)", (work in progress).
[HIERARCHY] Kompella K., "LSP Hierarchy with Generalized MPLS TE",
(work in progress).
[LINK-BUNDLING] Kompella K. et al., "Link Bundling in MPLS Traffic
Engineering", (work in progress).
[RFC3630] Katz D. et al., "Traffic Engineering (TE) Extensions to
OSPF Version 2".
[RFC3477] Kompella K. et al., "Signaling Unnumbered Links in Resource
ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477,
January 2003.
9. Informative references
[GMPLS-LCAS] Y. H. Kim et al, "Interaction between GMPLS RSVP-TE and
LCAS", draft-kim-ccamp-interaction-grsvpte-lcas-01.txt
Author's Addresses:
Wataru Imajuku
Imajuku, Tsukishima and Kim Expires - January 2006 10
draft-imajuku-ccamp-gmpls-vcat&lagr-req-00.txt June 2005
NTT Network Innovation Laboratories
1-1 Hikari-no-oka
Yokosuka Kanagawa 239-0847
Japan
Email: imajuku.wataru@lab.ntt.co.jp
Yukio Tsukishima
NTT Network Innovation Laboratories
1-1 Hikari-no-oka
Yokosuka Kanagawa 239-0847
Japan
Email: tsukishima.yukio@lab.ntt.co.jp
Young Hwa Kim
ETRI
61 Gajeong-dong Yuseong-gu
Daejeon 305-350
Korea
E-mail: yhwkim@etri.re.kr
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
Imajuku, Tsukishima and Kim Expires - January 2006 11
draft-imajuku-ccamp-gmpls-vcat&lagr-req-00.txt June 2005
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Imajuku, Tsukishima and Kim Expires - January 2006 12
