CCAMP Working Group Martin Vigoureux
Internet Draft Emmanuel Dotaro
Expires: December 2002 Dimitri Papadimitriou
Alcatel
Eiji Oki
Wataru Imajuku
Naoaki Yamanaka
NTT
June 2002
GMPLS Architectural Considerations for (Hybrid) Photonic Networks
draft-vigoureux-ccamp-gmpls-architecture-hpn-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026
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
1. Abstract
Optical networks could have been reduced to point-to-point links but
technology evolution led the way to an evolution trend. The concept
of optical transparency first took shape through the development of
photonic switching fabrics and is now being reinforced by the
continuous efforts produced to increase transmission distances.
Optical networking obviously can not be left aside of such
evolutions and so it is for the (in particular, GMPLS-based)
protocols that control these photonic networks. This document
highlights the enhancements that seem to be necessary for GMPLS to
cover these emerging trends (transparency, hybrid nodes) and fulfil
its role of a generalized control plane.
Vigoureux et al. December 2002 1
draft-vigoureux-ccamp-gmpls-architecture-hpn-00.txt June 2002
2. Summary for Sub-IP Area
2.1. Summary
See the Abstract above.
2.2. Where does it fit in the Picture of the Sub-IP Work
This work fits the CCAMP box.
2.3. Why is it Targeted at this WG
This draft is targeted at the CCAMP WG because it proposes a first
input on common signaling and routing protocol considerations
in multi-service environments.
2.4. Justification of Work
The WG should consider this document as it provides an architectural
framework for GMPLS-capable multi-service (with shared regeneration)
environments, topic that attracts increasing attention over past
years from the engineering community.
3. 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.
4. Introduction
Optical networks could have been reduced to point-to-point links but
technology evolution led the way to an evolution trend.
The concept of optical transparency first took shape through the
development of photonic switching fabrics and is now being
reinforced by the continuous efforts produced to increase
transmission distances. Matching these evolutions, are the efforts
made at the CCAMP WG for the definition a generalized control plane
architecture to encompass the networking issues that arise in such
networks.
In parallel to the introduction of heterogeneous networks with
limited conversion/regeneration functions, optical networks are
going beyond the restrictive transport function they first proposed.
Nodes are evolving to integrate multiple switching capabilities
jointly controlled in order to propose enhanced inter-working,
leading to resource utilization optimization. Such multi-level
switching architectures can be composed, for example, of a photonic
switch fabric topped by an opaque one offering regeneration function
and switching at another granularity. These architectures will be
referred in this document to as Hybrid Photonic Architectures (HPAs)
Vigoureux et al. December 2002 2
draft-vigoureux-ccamp-gmpls-architecture-hpn-00.txt June 2002
and the corresponding networks to as Hybrid Photonic Networks
(HPNs).
Optical networking obviously can not be left aside of such
fundamental evolutions and so it is for the (in particular, GMPLS-
based) protocols that control these photonic networks. Work ongoing
at the IPO working group reflects the need to consider topological
as well as physical constraints of photonic networks (see [IPO-
IMP]).
Unique aspect of hybrid photonic networks
-----------------------------------------
In hybrid photonic environments, constraints such as resource
availability are of utmost importance where regeneration/conversion
functions are limited and shared. In HPNs, resources are no longer
symmetrical with respect to regeneration/conversion functions. This
feature deeply impacts wavelength selection schemes (i.e. spectral
path computation) as well as wavelength continuity that will be
harder to achieve. This, in addition to the selection of
regeneration points conditioned by resource availability and signal
degradation.
This document highlights the enhancements that seem to be necessary
for GMPLS to cover these emerging trends (transparency, hybrid
nodes) and fulfil its role of a generalized control plane.
The first part of the document gives an overview of the impact of
optical transparency issues on signaling and how can they be
addressed. The second part is dedicated to routing considerations
while the third focuses on signaling.
5. Different Approaches
Establishing a connection throughout an optical network is achieved
in two steps: determination of an explicit spatial route followed by
a signaling phase selecting network resources (e.g. sequence of
wavelengths) to be used by the LSP. In this document, these two
phases are respectively referred to as spatial routing and spectral
routing.
The different schemes (see also [ONM-1]) listed below tend to
address the issues arising from the introduction of transparency in
optical networks. The impact of each scheme on the protocol
architecture is detailed afterwards.
5.1. First Scheme
The ingress node performs spatial and spectral routing decision.
Due to link-state scalability issues (and if the spectral routing
related information is not fed through the backward signaling flow),
this scheme is not considered in the current context.
Vigoureux et al. December 2002 3
draft-vigoureux-ccamp-gmpls-architecture-hpn-00.txt June 2002
5.2. Second Scheme
The ingress node performs spatial routing, while the intermediate
nodes perform spectral routing (hop-by-hop label selection is part
of spectral routing).
As currently specified, the GMPLS protocol suite definition reflects
this scheme. Per [GMPLS-SIG], the Label Set selection works
according to an AND scheme (see also [OKI-IPO]). Each hop restricts
the Label Set sent to the next hop from the one received from the
previous hop by performing an AND operation between the wavelength
referred by the labels it includes with the one available on the
ongoing interface. The constraint to perform this AND operation is
up to the node local policy (even if one expects a consistent policy
configuration throughout a given transparency domain).
When wavelength conversion is performed at an intermediate node, a
new Label Set is generated. The egress nodes selects one label in
the Label Set received at the node. According to the selected label
for the incoming link at the egress node, each label on the route is
determined in a hop-by-hop manner.
5.3. Third Scheme
The ingress node performs spatial routing while the egress node
performs spectral routing. Here, intermediate nodes may be allowed
performing some local processing.
Spectral related information is fed through signaling downward to
the egress node according to an ALL scheme (see also [OKI-IPO]). For
this purpose, at each hop, a Label Set object/TLV may be appended to
the global Label Set (more precisely to the list of Label Set
objects defining an end-to-end significant Label Set). Additional
processing may be performed at intermediate nodes depending on local
constraints.
At the end of the process and according to the collected spectral
information, the egress node determines all the labels on the route
considering the (individual) local constraints.
6. Routing Enhancements
All the previously listed schemes share the common approach of
performing spatial routing at ingress.
The computation of the spatial route is done upon information
flooded by an IGP such as OSPF or ISIS (see for OSPF [OSPF-TE], and
[GMPLS-OSPF] and for IS-IS [ISIS-TE] and [GMPLS-ISIS]). Obviously,
the more precise the information is, the more deterministic the
result is. However, assumption is made that periodical flooding and
link state information processing is not scalable if performed at
component link level. This statement might also depend on the
frequency of the update. Moreover, maintaining a routing adjacency
Vigoureux et al. December 2002 4
draft-vigoureux-ccamp-gmpls-architecture-hpn-00.txt June 2002
for each component link seems not realistic also for the same
scalability reasons. Therefore, the use of TE Links with stochastic
resource selection may be thus retained in this context.
Several constraints have already been envisaged to be taken into
account for constraint based spatial path computation. Bandwidth
availability and switching capability are, for example, information
available via TE Link Sub-TLVs (see [GMPLS-RTG]). However, it may be
appropriate to complete this information in order to reflect
enhanced link characteristics but also hybrid photonic network
features.
6.1.1. Physical Constraints
Due to the limited number of (shared) regeneration capability in
HPNs, physical constraints have to be considered during spatial
routing.
Since physical impairments (see for instance [IPO-IMP]) may be
relevant at the wavelength granularity, the latter requirement is
confronted to the same scalability problem if this information is to
be flooded by a link state routing protocol. A solution would be to
appropriately aggregate physical impairment information at the TE
Link level. This would enable providing a summarized information on
signal degradation enabling TE Link selection during the LSP path
computation.
However, if the considered physical impairments are nearly static or
have long variation period they may not be flooded and just made
available for path selection by using another mechanism such as
using the management plane. Otherwise means to aggregate physical
impairments information and to disseminate this information will be
needed.
6.1.2. Shared Resources Availability
In photonic networks, taking into account physical impairments
during spatial routing without any information about regeneration is
of little relevance. It is considered that the regeneration
capability information will be flooded by a link state routing
protocol such as OSPF or ISIS.
In HPNs, regeneration resources are distributed between optical
nodes and thus limited in terms of number of sharable entities. The
information relative to regeneration resources availability is thus
of a statistical nature if given at the TE link level. Thus one
expects to be capable to apply a stochastic approach for the
regeneration resource availability (defining implicitly their
status).
6.1.3. Waveband Switching
Vigoureux et al. December 2002 5
draft-vigoureux-ccamp-gmpls-architecture-hpn-00.txt June 2002
GMPLS protocol suite, as currently defined, supports waveband
switching through inverse multiplexing or switching of individual
(contiguous) wavelength components. It may be thus appropriate to
integrate wavebands in the switching hierarchy in order to reflect,
at the control plane level, waveband physical components
(multiplexer/demultiplexer) availability at the data plane. Detailed
extensions are described in [GMPLS-WBEXT].
Depending on the (passive/active) components used in an optical
network, wavelength spacing in the optical multiplex can vary. Some
components like multiplexer/demultiplexer impose or depend on that
spacing. It may be thus appropriate to detail the component
capability with respect to spacing, or to indicate the number of
supported wavelengths per waveband. Moreover, one may also expect in
case of (standardized) waveband nominal frequency values some
simplification during the corresponding wavelength assignment.
7. Signaling Considerations
The previous section highlighted the considerations with respect to
the routing protocols for enabling constraint based spatial routing
in hybrid photonic environments.
The current section focuses on the impact of HPNs on signaling
architecture by detailing spectral routing schemes mentioned above.
7.1. Schemes Comparison
In case of the second scheme (see Section 5.2.), the Label Set
reduction works according to an AND scheme. Each hop restricts the
label set sent to the next hop from the one received from the
previous hop by performing an AND operation between the wavelengths
referred by the Labels it includes the one available on the ongoing
interface.
This method generates a strong issue with regards to the probability
of having the Label Set reduced to an empty set of labels before
reaching the egress node (if each hop only proposes Labels referring
to wavelengths that are neither converted nor regenerated).
Note that using crank-back procedure can help reducing blocking
probability. A node may initiate a crank-back procedure if all
wavelengths referred in the Label Set coming from the upstream node
are not usable on the outgoing links to the downstream node.
- If conversion capabilities are available at this node and
accessible by the wavelengths referred in the Label Set coming from
the upstream node, the node may propose a new Label Set including
Labels accessible through conversion.
- If conversion functions are either not available in the node
or/nor accessible by the wavelengths referred in the Label Set
coming from the upstream node, the node may send a message
(including the Acceptable Label Set) to the upstream nodes in order
for the latter to propose new Labels (via conversion).
Vigoureux et al. December 2002 6
draft-vigoureux-ccamp-gmpls-architecture-hpn-00.txt June 2002
This message should contain an Acceptable Label Set (used as
feedback) for upstream nodes to intelligently propose new Labels.
Crank-back may reduce blocking probability but generates an issue
concerning signaling messages that may go back to the source and
forth many times before spectral path is found. Consequently, an
additional improvement should target intermediate Label Set
initialization point as (intermediate) destination of such messages
in order to avoid that the source (located behind the initialization
point) takes a contradictory decision based on the Acceptable Label
Set information. Moreover, it can be demonstrated that Label Set
utilization according to the AND scheme with crank-back feature is
sub-optimal with regards to the minimization of the number of
conversion/ regeneration points along the path. Nevertheless, in the
same context, only a global knowledge of spectral resources
availability along the spatial path enables optimal spectral path
computation.
It may be thus proposed to feed this information through signaling
using Label Set combined with an ALL scheme (i.e. also referred to
as ôexhaustive schemeö) and do spectral path computation at the
egress node. This refers to third scheme. Note that the exhaustive
property may be relaxed according to a local policy in order to
reduce the amount of information exchange from the source to the
destination (i.e. over the entire LSP).
At each hop, the local Label Set object/TLV is appended to the Label
Set (more precisely to the list of Label Let objects). Additional
processing might be done at intermediate nodes depending on local
constraints and policy. The egress node receives the spectral
information collected along at least one spatial path. It can then
compute, using this spectral information, the optimal combination or
transparent sub-paths.
The third scheme has an added value compared to the second one. It
enables ensuring (a better) wavelength continuity while jointly
addressing regeneration needs along the path, though it requires
having the knowledge (at egress) of the ability a node to access
regeneration for a given wavelength.
The issue here is to make a clear differentiation between a Path
message with resource reservation and a so-called probing message,
defined as a message only probing for the resource availability. For
that purpose an additional status of the request can be defined in
the signaling protocol (for instance a specific Administrative
status flag, other solutions may also be considered).
So the following method can be considered:
- Path/Label Request message(s), along several but at least one
spatial explicit routes computed at ingress.
Vigoureux et al. December 2002 7
draft-vigoureux-ccamp-gmpls-architecture-hpn-00.txt June 2002
- Computation at the egress of the best combination of
transparent sub-paths. (Wavelength Labels containing the
necessary information for this purposes)
- Resv/Label Mapping message through the selected path
- PathErr/Notification messages to the non-selected path (if one
considers that releasing the reserved resources must be
performed)
Note: Wavelength Selection and Reservation
Downstream Wavelength Selection and Reservation can only be
considered with Selective AND scheme. The ALL Scheme with forward
(downstream) reservation is precluded since it would generate an
overwhelming blocking probability, so this method can only be used
with a backward (upstream) reservation. Nevertheless, Soft Selection
(control plane only) can be considered either with a Selective AND
and Exhaustive ALL scheme.
7.2. Wavelength Label Space and Values
As specified in [GMPLS-SIG], the Wavelength label space may include
either absolute values (channel identifiers (Channel ID) also
referred to as wavelength identifiers) or relative values (channel
spacing also referred to as inter-wavelength spacing). The latter is
strictly confined to a per-port label space while the former could
be defined as a local or a global (per node) label space.
However, both wavelength selection schemes listed above require the
knowledge of the mapping between collected Labels and the wavelength
spectral-related information they locally refer. Therefore, in this
context, it is proposed to define an association between the Label
value and the wavelength spectral information.
In the second scheme, upstream nodes receiving an Acceptable Label
Set message, due to the crank-back procedure, must be able to
understand which wavelengths these Labels refer to. In third scheme,
the egress node must also know which wavelengths the Labels refer to
in order to achieve the expected wavelength continuity.
In order to decide where regeneration/conversion should be ideally
performed because of signal degradation/blocking probabilities,
knowledge of the capability of a wavelength to be regenerated is
also important.
The definition of the association between the Label value and the
wavelength spectral information is achieved by specifying semantic-
full and dedicated fields in the 32 bits Label. This specification
simply corresponds to a Label value assignment rule and still
ensures backward compatibility for nodes not able to understand the
hereafter defined semantic.
Vigoureux et al. December 2002 8
draft-vigoureux-ccamp-gmpls-architecture-hpn-00.txt June 2002
This Label may for instance include the following information
reflecting the spectral capabilities and attributes of the selected
Label:
R : set by the node proposing the Label. Informs whether the
corresponding wavelength can be regenerated or not.
C : set by the node proposing the Label. Informs whether the
corresponding wavelength can be converted or not.
A : set by the next downstream node receiving the proposed Labels.
Informs whether wavelengths can have access to regeneration
functionality in this node. This indication is primarily used by
nodes presenting blocking architectures with respect to their
amplification capabilities. For instance, amplification can be
performed in the C-Band, L-Band, S-Band, etc.
Wavelength Index : Identifies the wavelength in the Amplification
Band by considering minimum spacing.
Wavelength Identifier : Used to differentiate Labels (proposed for
example in a Label Set) that would have same values of the fields
listed above.
Other definitions not detailed here may also be used for the same
purpose. It should be also noticed that such label space definition
does not in the absolute sense bring any backward compatibility
issue with respect to [GMPLS-SIG]. In particular one assumes here
that local node may still convert these values into an internal one
no specific procedures should be defined to achieve backward
compatibility.
7.3. Comparison Example
The following example illustrates the different results that may be
obtained, for a spectral path computation, when using the second and
third schemes.
Consider a spatial path composed of nine wavelength switching nodes
with shared converters (both in the optical domain). In this
example, only available resources are mentioned and are described as
follows:
- Li-T means that interface i is transparent (neither going through
a converter converted nor a regenerator)
- Lj-C means that interface j is converted
Note that in case of nodes having conversion on all interfaces, the
second scheme is still compatible.
Available wavelengths on the outgoing links and thus not requiring
conversion (even though going through a converter) are considered as
transparent and corresponding Labels can thus be proposed.
Vigoureux et al. December 2002 9
draft-vigoureux-ccamp-gmpls-architecture-hpn-00.txt June 2002
Node 1 has available L2-C and L4-C
Node 2 has available L4-T and L6-C
Node 3 has available L4-T and L6-T
Node 4 has available L4-T, L6-T and L7-C
Node 5 has available L4-T, L6-T and L7-T
Node 6 has available L6-T and L7-T
Node 7 has available L6-T and L7-T
Node 8 has available L6-T and L8-C
Node 9 has available L6-T and L8-C
For second scheme (with crank-back) wavelength selection will go as
follows: Node 1 proposes the Labels L2 and L4 that Node 2 restricts
to L4 (only transparent wavelength). Reaching Node 5, the Label L4
is sent towards Node 6, which has free output interfaces but no
available conversion function.
Message is thus sent back upstream (maybe with an Acceptable Label
Set, L6 and L7 in this case) until a node can perform conversion.
Therefore, the feedback (i.e. the Acceptable Label Set) is used by
Nodes having enough free resources to perform wavelength conversion.
Here, the message arrives back to Node 4 which can perform
conversion from L4 to L7. Node 4 sends Label Set L7 which is
propagated down to Node 8. L7 is not available at Node 8 output but
can be converted to L8 (Node 8 does crank-back on itself).
The resulting spectral path can be represented as:
L4 L4 L4 L7 L7 L7 L7 L8
N1------N2------N3------N4------N5------N6------N7------N8------N9
Using the third scheme, each node, proposing all of its free output
Labels, the result would have been:
L4 L6 L6 L6 L6 L6 L6 L6
N1------N2------N3------N4------N5------N6------N7------N8------N9
Therefore, the second scheme will result in using two conversion
points (at Node 4 and Node 8) along the path, while third scheme
will result in using only one (at Node 2).
8. Other issues
This section details other GMPLS architectural issues in the scope
of the hybrid photonic networks:
8.1 Bi-directional LSPs
When using the second selection scheme, two mechanisms must be
considered depending on the directionality of the LSP:
1) Unidirectional LSP: (downstream) label set
2) Bi-directional LSP: (downstream) label set and upstream label
Vigoureux et al. December 2002 10
draft-vigoureux-ccamp-gmpls-architecture-hpn-00.txt June 2002
The first improvement that may be provided is to extend the upstream
label to an upstream label set, thus one would have the following
symmetric approach when using an AND label selection scheme:
1) Unidirectional selection scheme: (downstream) label set
2) Bi-directional selection scheme: (downstream) label set and
upstream label set
The Resv/Label mapping message will then either include the
downstream label in addition to the upstream label, in case of bi-
directional LSP. Notice that here both labels are selected at the
egress. Detailed extensions concerning the upstream label set are
described in [OKI-UPSTREAM].
The same applies in case of exhaustive label selection scheme. The
ALL scheme when used for bi-directional path setup must take into
account not only outgoing spectral routing information but also
incoming spectral routing information and perform the selection at
the destination based on a correlation basis for both upstream and
downstream flows.
8.2 Prioritized Label Sets
Signaling extensions may be also considered to ease forward-link
label unavailability when the downstream label selection is
restricted by the upstream node using the Label Set (see [GMPLS-
SIG]). [OZU-FLAGS] allows relaxing backward-link label collision by
introducing a Flagged Label Set object/TLV in order to prioritize
the reservation of the labels included in the Label Set and enabling
to decrease the forward- and backward-link blocking probability.
In order to prioritize the label reservation, each set of labels is
inserted by each hop along the path into the Flagged Label Set with
a certain priority. Each node keeps track of each label by using a
local timestamp indicating when the label has been reserved but not
selected yet with respect to any other previous label set. A pool
points to these labels and provides a gray area for the labels,
which are subject to collision. It may be seen as an intermediate
state between the labels belonging to the used pool of labels
(reserved and selected) and the ones belonging to the available pool
of labels (neither reserved nor selected).
Other prioritization methods may be considered in future releases of
this document.
8.3 Branching and K-(C)SPF
TBD.
9. Security Considerations
This memo does not introduce new security consideration from the
ones already detailed in the GMPLS protocol suite.
Vigoureux et al. December 2002 11
draft-vigoureux-ccamp-gmpls-architecture-hpn-00.txt June 2002
10. References
[GMPLS-ARCH] E.Mannie (Editor) et al.,
"Generalized Multi-Protocol Label Switching (GMPLS)
Architecture", Work in progress,
draft-ietf-ccamp-gmpls-architecture-02.txt
[GMPLS-ISIS] Kompella, K., Rekhter, Y., Banerjee, A. et al.,
"IS-IS Extensions in Support of Generalized MPLS", Work
in progress,
draft-ietf-isis-gmpls-extensions-12.txt
[GMPLS-OSPF] Kompella, K., Rekhter, Y., Banerjee, A. et al.,
"OSPF Extensions in Support of Generalized MPLS", Work
in progress,
draft-ietf-ccamp-ospf-gmpls-extensions-07.txt
[GMPLS-SIG] Ashwood-Smith, P. et al.,
"Generalized MPLS-Signaling Functional Description",
Work in progress,
draft-ietf-mpls-generalized-signaling-08.txt
[GMPLS-RTG] Kompella, K., Rekhter, Y., Banerjee, A. et al.,
"Routing Extensions in Support of Generalized MPLS",
Work in progress,
draft-ietf-ccamp-gmpls-routing-04.txt
[GMPLS-WBEXT] Douville R. et al.,
"Extensions to Generalized MPLS for Waveband
Switching", Work in progress,
draft-douville-ccamp-gmpls-waveband-extensions-01.txt
[IPO-IMP] A. Chiu et al.,
"Impairments And Other Constraints On Optical Layer
Routing", Work in progress,
draft-ietf-ipo-impairments-02.txt.
[ISIS-TE] Smit, H., Li, T.,
"IS-IS Extensions for Traffic Engineering", Work in
progress,
draft-ietf-isis-traffic-04.txt
[OKI-IPO] E. Oki et al.,
ôRequirements of optical link-state information for
traffic engineeringö, Work in progress,
draft-oki-ipo-optlink-req-00.txt
[OKI-UPSTREAM] E. Oki et al.,
ôUpstream Label Set Support in RSVP-TE extensionsö,
Work in progress,
draft-oki-ccamp-upstream-labelset-00.txt
Vigoureux et al. December 2002 12
draft-vigoureux-ccamp-gmpls-architecture-hpn-00.txt June 2002
[OZU-FLAGS] T.Ozugur et al.,
ôLabel Set Priority and Flagging Operationsö, Work in
progress,
draft-ozugur-ccamp-gmpls-label-flag-00.txt
[ONM-1] ôA comparative study of distributed protocols for
wavelength reservation in WDM Optical networks, Optical
Network Magazine, January 2002.
[OSPF-TE] Katz, D., Yeung, D.,
"Traffic Engineering Extensions to OSPF", Work in
progress,
draft-katz-yeung-ospf-traffic-06.txt
11. Acknowledgments
We would like, here, to thank Richard Douville, Olivier Audouin,
Emmanuel Desmet as well as Amaury Jourdan and Bernard Sales.
The authors would like also to thank Kohei Shiomoto and Nobuaki
Matsuura of NTT for their contribution to this memo.
12. Author's Addresses
Eiji Oki (NTT)
3-9-11 Midori
Musashino, Tokyo 180-8585, Japan
Email: oki.eiji@lab.ntt.co.jp
Wataru Imajuku (NTT)
1-1 Hikari-no-oka
Yokosuka, Kanagawa 239-0847, Japan
Email: imajuku@exa.onlab.ntt.co.jp
Naoaki Yamanaka (NTT)
3-9-11 Midori-cho
Musashino-shi, Tokyo 180-8585, Japan
Email: yamanaka.naoaki@lab.ntt.co.jp
Emmanuel Dotaro (Alcatel)
Route de Nozay, 91460 Marcoussis, France
Phone: +33 1 6963-4723
Email: emmanuel.dotaro@alcatel.fr
Dimitri Papadimitriou (Alcatel)
Francis Wellesplein 1, B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491
Email: dimitri.papadimitriou@alcatel.be
Martin Vigoureux (Alcatel)
Route de Nozay, 91460 Marcoussis, France
Phone: +33 1 6963-1852
Vigoureux et al. December 2002 13
draft-vigoureux-ccamp-gmpls-architecture-hpn-00.txt June 2002
Email: martin.vigoureux@alcatel.fr
Vigoureux et al. December 2002 14
draft-vigoureux-ccamp-gmpls-architecture-hpn-00.txt June 2002
Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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."
Vigoureux et al. December 2002 15