Network Working Group
Internet Draft Kenji Kumaki
Category: Informational KDDI Corporation
Expires: August 2006 Tomohiro Otani
KDDI R&D Labs
Shuichi Okamoto
NICT
Kazuhiro Fujihara
Yuichi Ikejiri
NTT
Communications
February 2006
Requirements for IP/MPLS-GMPLS interworking in support of GMPLS
deployment
draft-kumaki-ccamp-mpls-gmpls-interwork-reqts-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 working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
K.Kumaki et al. Expires - August 2006 [Page 1]
Requirements for IP/MPLS-GMPLS interworking in support of GMPLS
deployment February 2006
This document describes Service Provider requirements for IP/MPLS-
GMPLS interworking in support of GMPLS deployment.
The main objective is to present a set of requirements and scenarios
which result in general guidelines for the definition, selection and
specification of a technical solution addressing these requirements
and supporting the scenarios. Specification for this solution itself
is out of scope in this document.
Conventions used in this document
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.
Table of Contents
1. Introduction...................................................3
2. Terminology....................................................4
3. Problem Statement..............................................4
4. Reference model................................................5
5. Application Scenario...........................................5
5.1 Overlay model..............................................6
5.2 Integrated model...........................................6
5.3 Augmented model............................................6
6. Detailed Requirements..........................................7
6.1 Software Upgrade Requirement...............................8
6.2 Use of GMPLS network resources in IP/MPLS networks.........8
6.3 Routing adjacency for IP/MPLS networks over GMPLS networks.8
6.4 Mapping routing information between IP/MPLS and GMPLS......8
6.5 Mapping signaling information between MPLS and GMPLS.......9
6.6 Establishment of GMPLS LSPs triggered by end-to-end MPLS LSPs
signaling......................................................9
6.7 Establishment of end-to-end MPLS LSPs having diverse paths
over GMPLS network.............................................9
6.8 Advertisement of TE / IP reachability information via GMPLS
domain.........................................................9
6.9 Selective advertisement of TE/IP reachability information via
a border node..................................................9
6.10 Interworking of MPLS and GMPLS protection................10
6.11 Separation of IP/MPLS domain and GMPLS domain............10
6.12 Failure recovery.........................................10
6.13 Complexity and Risks.....................................10
6.14 Scalability consideration................................10
6.15 Performance consideration................................11
6.16 Management consideration.................................11
7. Security Considerations.......................................11
K.Kumaki et al. Expires - August 2006 [Page 2]
Requirements for IP/MPLS-GMPLS interworking in support of GMPLS
deployment February 2006
8. IANA Considerations...........................................12
9. Normative References..........................................12
10. Informative References.......................................12
11. Acknowledgments..............................................12
12. Author's Addresses...........................................12
13. Intellectual Property Statement..............................13
1. Introduction
Recently, the deployment of a GMPLS network is planned or under
investigation among many service providers and some of very advanced
research networks have been already operated based on GMPLS
technology. GMPLS is developed as an extension of MPLS in order to
mainly control a transport network consisting of TDM cross-connect,
optical/lambda switches, and fibers. By introducing GMPLS technology,
some service providers expect that IP/MPLS network connectivity is
effectively and reliably established over the GMPLS network. If MPLS
and GMPLS protocols can interwork with each other, the introduction
of GMPLS would be more beneficial for service providers, because this
is expected to improve the resource utilization, network resiliency
and manageability all over the network, less impacting the existing
IP/MPLS networks.
On the other hand, GMPLS protocols additionally define the packet
switch capable mechanism, although existing MPLS networks already
achieve the almost same functionalities and are being well-operated.
Some service providers are considering to gradually replace all the
IP/MPLS routers with GMPLS routers or upgrade the software so as to
support GMPLS in conjunction with the introduction of GMPLS
controlled optical networks.
In both cases, there is no clear definition and standardization work
so far to interwork between IP/MPLS routers as well as GMPLS routers,
i.e. IP/MPLS networks and GMPLS networks. In order to accelerate the
deployment of GMPLS technology, MPLS/GMPLS interworking is a key to
gain more benefit than without any interworking.
These types of network architecture to investigated, however, are
much varied among service providers, and as a result, the
requirements in support of those may be different from each other.
In order to create the definition of MPLS/GMPLS interworking
technology, the concrete requirement is preferably defined from the
point of operational experience of MPLS/GMPLS networks and future
view on these technologies by collecting the input and requirements
from various service providers.
K.Kumaki et al. Expires - August 2006 [Page 3]
Requirements for IP/MPLS-GMPLS interworking in support of GMPLS
deployment February 2006
Considering such environment, this document focuses on the
requirement of IP/MPLS-GMPLS interworking especially in support of
GMPLS deployment.
2. Terminology
IP/MPLS network: Service Provider Network where MPLS switching
capabilities and signaling control (e.g., ones
described in [RFC3031]) are activated in addition
to IP routing protocols.
LSP: Label Switched Path
PSC: Packet Switch Capable
LSC: Lambda Switch Capable
FA-LSP: Forwarding Adjacency Label Switched Path
Head-end LSR: ingress LSR
Tail-end LSR: egress LSR
LSR: Label Switched Router
MPLS LSP: Multi Protocol Label Switching LSP
3. Problem Statement
GMPLS technology is deployed or will be deployed in various forms to
provide a highly efficient transport for existing IP/MPLS network,
depending on the deployment model of each service provider. Some
service providers may allow the hybrid architecture of IP/MPLS and
GMPLS so that the introduction of GMPLS technology has less impact on
an existing IP/MPLS network with regard to routing instance,
addressing and the running software. On the other hand, some service
providers may need to control almost all devices by a single control
plane of GMPLS, which may require the running software upgrade.
In order to operate such a hybrid network appropriately and
effectively, clear definition should be formulated so as to cover
each service provider's strategy.
In terms of MPLS/GMPLS signaling, although the created GMPLS LSP over
optical networks will be utilized by the IP/MPLS network, the clear
mechanism of how to use it has not yet been defined. On the other
hand, if the routing mechanism is considered, the method to transport
routing information has not yet been also defined between IP/MPLS
K.Kumaki et al. Expires - August 2006 [Page 4]
Requirements for IP/MPLS-GMPLS interworking in support of GMPLS
deployment February 2006
networks and GMPLS networks. Feature richness of MPLS and GMPLS
technology allows service providers to use a set of options on how
GMPLS services can be used by IP/MPLS networks. In this document,
the requirement for IP/MPLS-GMPLS interworking is presented with some
operations considerations associated with use of GMPLS services by
IP/MPLS networks.
Note that an IP/MPLS-GMPLS interworking to deploy GMPLS technology is
not only tentatively required for a migration from MPLS RSVP-TE to
GMPLS RSVP-TE but also permanently required for the use of LDP and
IGP (e.g. OSPF and IS-IS) instead of MPLS RSVP-TE in IP/MPLS networks.
4. Reference model
The reference model used in this document is shown in Figure 1. As
indicated in [RFC3945], the optical transport network consists of,
for example, GMPLS controlled OXCs and GMPLS-enabled IP/MPLS routers.
| | | |
|IP/MPLS network |------------------------------|IP/MPLS network |
| | | |
| Optical Transport |
| (GMPLS) Network |
+---------+ +--------+ +------+ +------+ +--------+ +---------+
| | | | | | | | | | | |
| IP/MPLS +--+ GMPLS +--+ +--+ +--+ GMPLS +--+ IP/MPLS |
| Service | |Enabled | | OXC1 | | OXC2 | |Enabled | | Service |
| Network +--+ router | | +--+ | | router +--+ Network |
| | | | | | | | | | | |
+---------+ +--------+ +------+ +------+ +--------+ +---------+
Figure 1. Reference model of MPLS/GMPLS interworking
IP/MPLS network connectivity is provided through GMPLS LSP which is
created between GMPLS routers. In this document, the requirement how
the IP/MPLS network and the GMPLS network are interworked is
described in order to effectively operate the entire network and
smoothly deployed the GMPLS network.
5. Application Scenario
This section describes three different scenarios to deploy GMPLS
technology.
From the deployment point of view, GMPLS architecture document lists
[RFC3945] three different scenarios in which GMPLS technology can be
K.Kumaki et al. Expires - August 2006 [Page 5]
Requirements for IP/MPLS-GMPLS interworking in support of GMPLS
deployment February 2006
deployed: overlay, integrated and augmented.
The key difference among these models is how much and what kind of
network information can be shared between packet (e.g. PSC) and
optical (e.g. LSC) domains.
In this section, in case that GMPLS technology is deployed in
existing IP/MPLS networks, pros and cons of each model are discussed.
5.1 Overlay model
In overlay model, all the devices in optical domains have no
visibility into others topology and/or routing information such as
packet network (e.g. IP/MPLS service network) and vice versa.
But IP/MPLS domain and optical domain can interact with signaling
operation.
Overlay model is suitable for such scenario, however it does not
offer the benefits of integrated model approach for efficient
resource utilization, optimal routing, and protection and restoration
between IP/MPLS and optical networks.
Note that some service providers need a way to make effective use
of GMPLS network resources (e.g. bandwidth, protection and recovery)
for the IP/MPLS service networks.
5.2 Integrated model
In integrated model, since all the devices in optical domains and
IP/MPLS domains share the same topology and routing information with
the same IGP instance, it requires all the devices within peer model
to be MPLS/GMPLS aware.
This model is also suitable, where optical transport and IP/MPLS
service networks are operated by a single entity.
Currently, many service providers have traditionally built their
networks, where optical transport and IP/MPLS service networks belong
to different operation, management and ownership. The most important
thing is that service providers want to operate and manage their
networks independently, and deploy them without changing existing
IP/MPLS network topologies, protocols and scalability.
But in this model, in case that a lot of devices exist in a network,
there are scalability issues. Note that most of real service
providers have thousands or tens of thousands of devices in real
networks.
5.3 Augmented model
Augmented model is suitable in the scenario, where optical transport
and IP/MPLS service networks are administrated by different entities
and the service provider would like to maintain a separation between
K.Kumaki et al. Expires - August 2006 [Page 6]
Requirements for IP/MPLS-GMPLS interworking in support of GMPLS
deployment February 2006
IP/MPLS and Optical layers while getting the benefits of integrated
model approach.
In augmented model, as shown in figure 2, devices within optical
domains have no visibility into others topology and/or routing
information, except the border nodes. This will help augmented model
to accommodate both MPLS based or non-MPLS based service networks
connected to border nodes, as long as the border node in augmented
model can support GMPLS control plane. Only the border node can share
optical domains and IP/MPLS domains. Once IP/MPLS nodes signal to
border nodes, the border nodes make effective use of GMPLS network
resources (e.g. bandwidth, protection and recovery) for the IP/MPLS
service networks.
Note that an IP/MPLS routing instance and GMPLS routing instance have
different routing instances at a border node.
One of the main advantages of the augmented model in the context of
GMPLS deployment is that it does not require existing IP/MPLS
networks to be GMPLS aware. Only border nodes need to be upgraded
with the GMPLS functionality. In this fashion, the augmented model
renders itself for incremental deployment of the optical regions,
without requiring reconfiguration of existing areas/ASes, changing
operation of IGP and EGP or software upgrade of the existing IP/MPLS
service networks.
Furthermore, to deploy GMPLS technology without changing the existing
IP/MPLS networks as much as possible is desirable by simply
establishing a routing adjacency at IP/MPLS instance between border
nodes.
| | | |
|IP/MPLS network |------------------------------|IP/MPLS network |
| | | |
| Optical Transport |
| (GMPLS) Network |
+---------+ +--------+ +------+ +------+ +--------+ +---------+
| | | | | | | | | | | |
| IP/MPLS +--+ Border +--+ +--+ +--+ Border +--+ IP/MPLS |
| Service | | node | | OXC1 | | OXC2 | | node | | Service |
| Network +--+ | | +--+ | | +--+ Network |
| | | | | | | | | | | |
+---------+ +--------+ +------+ +------+ +--------+ +---------+
Figure 2. Augmented Model
6. Detailed Requirements
This section describes detailed requirements for IP/MPLS-GMPLS
interworking in support of GMPLS deployment.
K.Kumaki et al. Expires - August 2006 [Page 7]
Requirements for IP/MPLS-GMPLS interworking in support of GMPLS
deployment February 2006
6.1 Software Upgrade Requirement
The solution SHOULD provide the way not to upgrade all IP/MPLS
routers to GMPLS capable routers.
Generally speaking, it is not practical to upgrade all IP/MPLS
routers to GMPLS capable routers in real service provider networks
due to a number of reasons. Especially, in case of accommodating
enterprise customers, it is difficult for service providers to
upgrade from IP/MPLS capable routers to GMPLS capable routers.
This means that some routers would not be upgraded to support GMPLS
and some routers would support it in the IP/MPLS production networks.
6.2 Use of GMPLS network resources in IP/MPLS networks
The solution SHOULD provide the ability to make effective use of
GMPLS network resources (e.g. bandwidth, protection & recovery) by
the IP/MPLS service networks.
Most of service providers have different networks for various
services; their GMPLS deployment plans are to have these service
networks use a common GMPLS controlled optical network as a core
network of various services.
6.3 Routing adjacency for IP/MPLS networks over GMPLS networks
The solution SHOULD provide the ability to establish a routing
adjacency at IP/MPLS instance between border nodes.
Most of service providers expect to deploy GMPLS technology without
changing the existing IP/MPLS networks as much as possible. In case
that GMPLS technology is deployed at a border node, the routing
adjacency at IP/MPLS instance between the border nodes is required.
Note that the routing adjacency is not established between IP/MPLS
routers in case of using FA-LSPs.
6.4 Mapping routing information between IP/MPLS and GMPLS
The solution SHOULD provide the ability to map routing information
between IP/MPLS and GMPLS. From an IP/MPLS routing domain point of
view, the routers in the IP/MPLS domain should be able to see a GMPLS
LSP as a link or TE link. Furthermore, they should be able to choose
an appropriate GMPLS LSP in GMPLS optical domain as a link or TE link.
In this case, routers in the IP/MPLS domain can choose a link or TE
link based on some policy such as optimality, diversity, protected or
QoS inferred. It would enable an IP/MPLS network operating LDP/IGP
(e.g. OSPF and IS-IS) as well as RSVP-TE to use GMPLS as an effective
transport network.
K.Kumaki et al. Expires - August 2006 [Page 8]
Requirements for IP/MPLS-GMPLS interworking in support of GMPLS
deployment February 2006
6.5 Mapping signaling information between MPLS and GMPLS
The solution SHOULD provide the ability to map signaling information
between MPLS and GMPLS. From an IP/MPLS signaling domain point of
view, the routers in IP/MPLS domain should be able to signal over
GMPLS optical domain. In this case, an interworking between MPLS and
GMPLS protocol is needed. Note that it is supposed that MPLS
signaling here is RSVP based signaling.
6.6 Establishment of GMPLS LSPs triggered by end-to-end MPLS LSPs
signaling
The solution SHOULD provide the ability to establish end-to-end MPLS
LSPs over GMPLS network regardless of existence of FA-LSPs in GMPLS
network. When there are no FA-LSPs in it, they should be set up
triggered by the signaling of MPLS LSP.
6.7 Establishment of end-to-end MPLS LSPs having diverse paths over
GMPLS network
The solution SHOULD provide the ability to establish end-to-end
LSPs having diverse paths including diverse GMPLS FA-LSPs
corresponding to the request of the head-end MPLS LSR for protection
of MPLS LSPs. The GMPLS network SHOULD assure the diversity of GMPLS
FA-LSPs, even if their ingress nodes in GMPLS network are different.
6.8 Advertisement of TE / IP reachability information via GMPLS domain
The solution SHOULD provide the ability to control advertisements of
TE information and/or IP reachability information of IP/MPLS service
networks via GMPLS network regardless of existence of FA-LSPs.
The TE / IP reachability information within the same MPLS service
networks should be exchanged in order for a head end LSR of the MPLS
network to compute an LSP to a tail end LSR over the GMPLS network.
On the other hand, the TE / IP reachabality information SHOULD NOT be
advertised to the other IP/MPLS service networks in order to avoid
establishing undesirable connections.
6.9 Selective advertisement of TE/IP reachability information via a
border node
The solution SHOULD provide the ability to distribute TE/IP
reachability information
from the GMPLS network to IP/MPLS networks selectively, which are
useful for the head-end MPLS routers to compute MPLS LSPs.
K.Kumaki et al. Expires - August 2006 [Page 9]
Requirements for IP/MPLS-GMPLS interworking in support of GMPLS
deployment February 2006
6.10 Interworking of MPLS and GMPLS protection
The solution SHOULD provide the ability to select GMPLS protection
type with the option by protected MPLS LSPs.
If MPLS LSPs are protected using MPLS FRR [RFC4090], when an FRR
protected packet LSP is signaled, we should be able to select
protected FA-LSPs from GMPLS network. In terms of MPLS protection,
MPLS path message can include some flags in FAST REROUTE object
and SESSION_ATTRIBUTE object.
In terms of GMPLS protection, there are both signaling aspects
[RFC3471] [RFC3473] and routing aspects [RFC4202].
6.11 Separation of IP/MPLS domain and GMPLS domain
The solution SHOULD provide the ability to separate IP/MPLS domain
and GMPLS domain.
Most of service providers have had different networks for every
service, where optical networks and IP/MPLS networks belong to
different operation, management and ownership. The most important
thing is that service providers want to operate and manage their
networks independently, and deploy them without changing existing
IP/MPLS network topologies and protocols and without affecting
scalability.
6.12 Failure recovery
The solution SHOULD provide failure recovery in optical domain
without impacting IP/MPLS domain and vice versa.
Failure in optical routing domain SHOULD NOT affect services in
IP/MPLS routing domain and failure can be restored/repaired in
optical domain without impacting IP/MPLS domain and vice versa.
But in case that failure in optical domain associates with IP/MPLS
domain, some kind of notification of the failure may be transmitted
to IP/MPLS domain and vice versa.
6.13 Complexity and Risks
The solution SHOULD NOT introduce unnecessary complexity to the
current operating network to such a degree that it would affect the
stability and diminish the benefits of deploying such a solution over
service provider networks.
6.14 Scalability consideration
The solution MUST have a minimum impact on network scalability for
deploying GMPLS technology in the existing IP/MPLS networks.
Scalability of GMPLS deployment in the existing IP/MPLS networks MUST
address the following consideration.
K.Kumaki et al. Expires - August 2006 [Page 10]
Requirements for IP/MPLS-GMPLS interworking in support of GMPLS
deployment February 2006
- the number of GMPLS capable node (e.g. the number of non-PSC GMPLS
capable node)
- the number of MPLS capable node
- the number of IP capable node
- the number of OSPF capable node
- the number of OSPF non-backbone area
- the number of BGP capable node
6.15 Performance consideration
The solution SHOULD be evaluated with regard to the following
criteria.
- the number of routing instance
- Failure and restoration time
- Impact and scalability of the control plane due to added
overheads and so on
- Impact and scalability of the data/forwarding plane due to added
overheads and so on
6.16 Management consideration
Manageability of GMPLS deployment in the existing IP/MPLS networks
MUST addresses the following consideration for section 6.
- need for a MIB module for control plane and monitoring
- need for diagnostic tools
Basically MIB module should be implemented per routing instance.
Today, diagnostic tools can detect failures of control plane and data
plane for general MPLS TE LSPs [LSP-PING].
The diagnostic tools must detect failures of control and data plane
for general GMPLS TE LSPs.
Especially, in case that an interworking between MPLS and GMPLS
protocol is done, a failure between them MUST be detected.
Furthermore, many service providers have traditionally built their
networks, where optical transport and IP/MPLS service networks belong
to different operation, management and ownership. The most important
thing is that service providers want to operate and manage their
networks independently.
7. Security Considerations
Many service providers have traditionally built their networks, where
optical transport and IP/MPLS service networks belong to different
K.Kumaki et al. Expires - August 2006 [Page 11]
Requirements for IP/MPLS-GMPLS interworking in support of GMPLS
deployment February 2006
operation, management and ownership. The most important thing is that
service providers want to operate and manage their networks
independently. In that sense, operators SHOULD limit to access their
service nodes. Especially, in case that a border node is deployed,
operators SHOULD limit to access a specific instance. Furthermore,
operators SHOULD limit to be able to issue some commands.
8. IANA Considerations
This requirement document makes no requests for IANA action.
9. Normative References
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC3945, October 2004.
[RFC4090] Pan, P., Swallow, G. and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC3471, January
2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions ", RFC 3473, January 2003.
[RFC4202] Kompella, K., Rekhter, Y., "Routing Extensions in Support
of Generalized Multi-Protocol Label Switching (GMPLS)",
RFC4202, October 2005.
10.Informative References
[LSP-PING] Kompella, K. and G. Swallow, "Detecting MPLS Data Plane
Failures", Work in Progress, January 2006.
11.Acknowledgments
The author would like to express the thanks to Raymond Zhang for his
helpful and useful comments and feedbacks.
12.Author's Addresses
Kenji Kumaki
KDDI Corporation
Garden Air Tower
Iidabashi, Chiyoda-ku,
Tokyo 102-8460, JAPAN
K.Kumaki et al. Expires - August 2006 [Page 12]
Requirements for IP/MPLS-GMPLS interworking in support of GMPLS
deployment February 2006
Email: ke-kumaki@kddi.com
Tomohiro Otani
KDDI R&D Laboratories, Inc.
2-1-15 Ohara Kamifukuoka Phone: +81-49-278-7357
Saitama, 356-8502. Japan Email: otani@kddilabs.jp
Shuichi Okamoto
NICT JGN II Tsukuba Reserach Center
1-8-1, Otemachi Chiyoda-ku, Phone : +81-3-5200-2117
Tokyo, 100-0004, Japan E-mail :okamot-s@nict.go.jp
Kazuhiro Fujihara
NTT Communications Corporation
Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku
Tokyo 163-1421, Japan
EMail: kazuhiro.fujihara@ntt.com
Yuichi Ikejiri
NTT Communications Corporation
Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku
Tokyo 163-1421, Japan
EMail: y.ikejiri@ntt.com
13.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.
K.Kumaki et al. Expires - August 2006 [Page 13]
Requirements for IP/MPLS-GMPLS interworking in support of GMPLS
deployment February 2006
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
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 (2006). 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.
K.Kumaki et al. Expires - August 2006 [Page 14]