Internet DRAFT - draft-caviglia-mp2cpcp2mp
draft-caviglia-mp2cpcp2mp
Network Working Group
Internet Draft Diego Caviglia
Marconi
Dino Bramanti
Marconi
Nicola Ciulli
NextWorks
Document: draft-caviglia-mp2cpcp2mp-03.txt
Proposed Status: Updates RFC 3473
Expires: April 2006 October 2005
GMPLS Signaling Extensions for the Transfer of Ownership of Label
Switched Paths Between the Management and Control Planes
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
During migration scenarios it may be desirable to transfer the
ownership of a Label Switched Path (LSP) from the Management Plane
(MP) to the Control Plane (CP), or vice versa. If the LSP is carrying
traffic this change needs to be made "in service," that is, without
affecting traffic.
This memo provides minor extensions to the Generalized Multi Protocol
Label Switching (GMPLS) signaling protocol, GRSVP_TE (Generalized
Resource Reservation Protocol with Traffic Engineering Extensions),
Caviglia et al. Expires - April 2006 [Page 1]
draft-caviglia-mp2cpcp2mp-03 October 2005
to enable such transfer of ownership and describes the proposed
procedures.
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 [1].
Table of Contents
1. Introduction...................................................2
2. Problem Explanation............................................3
3. Proposed solution..............................................3
4. LSP Ownership Handover Procedure Between Management And Control
Planes............................................................5
4.1 "MP to CP handover" - LSP Ownership Transfer From Management
Plane To Control Plane.........................................5
4.2 MP to CP Handover Procedure Failure Handling...............8
4.3 "CP to MP handover" - LSP Ownership Transfer From Control
Plane To Management Plane..................................8
4.4 CP to MP Handover Procedure Failure Handling...............9
5. An Alternative Way of doing MP to CP Handover.................10
6. RSVP Message Formats..........................................11
6.1 Object Modification.......................................11
7. Security Considerations.......................................11
8. IANA Consideration............................................12
9. References....................................................12
10. Acknowledgments..............................................12
Author's Addresses...............................................13
1. Introduction
In a typical, traditional transport network scenario, Data Plane
connections between two endpoints are controlled basically by means
of a Network Management System (NMS) operating within Management
Plane (MP). NMS/MP is the owner of such transport connections, being
responsible of their set up, tear down and maintenance. The adoption
and use of a GMPLS Control Plane over networks that are controlled by
NMS at Management Plane level and that are already in service could
not be considered a green field application. In this context, let's
indicate with the term Label Switched Path (LSP) the Data Plane
forwarding path and Data Plane state associated to a connection,
whose control is owned by either Management or Control Plane (via
GRSVP-TE). In a mixed scenario, LSPs owned by Management Plane and
LSPs owned by Control Plane have to coexist and a way to move their
Caviglia et al. Expires - April 2006 [Page 2]
draft-caviglia-mp2cpcp2mp-03 October 2005
control and ownership between planes, while preserving corresponding
Data Plane traffic, is needed. It is in fact possible that a network
operator wants to move the control of a Management Plane owned
transport connection to Control Plane and, in the same way, the
opposite operation is also needed. In this memo let's indicate with
"MP to CP handover" the procedure that is aimed at moving the control
and ownership of a transport connection owned by Management Plane to
Control Plane. Let's call "CP to MP handover" the opposite procedure,
aimed at moving the ownership of a LSP from Control Plane to
Management Plane.
2. Problem Explanation
Having the ownership of a LSP means basically having the access to
the information associated to a physical Data Plane connection
between two endpoints (ingress and egress of LSP) that traverses a
list of nodes. The owner of a LSP has to store and use such
information (LSP hop list, associated TE information etc.) to control
completely the LSP. Let's take the case of a Data Plane connection
between an ingress node and an egress node, which has been set up by
means of NMS. The network resources allocated to this connection
cannot be used or controlled by GRSVP-TE as it doesn't have any
information record about it. If a standard GRSVP-TE setup request
over the same resources was issued, the nodes will reject it, as they
find the involved resources already allocated. A standard GRSVP-TE
release request for that LSP wont be successful as well, because LSP
related information to be matched with the one sent in signaling
messages is not available at Control Plane level.
If a Data Plane connection between an ingress node and an egress has
been set up via GRSVP-TE signaling, all the info related to the LSP
is present at Control Plane level which is the owner of that
connection. If NMS wants to take over the LSP, the Control Plane has
to be informed that involved resources are no more under its control.
In both cases, the point is that the Data Plane connection has to
stay up, but related information allowing control of the LSP has to
be handed over to Control Plane or Management Plane. In other words,
a handover of LSP ownership between planes means that Data Plane
circuit has to stay untouched in terms of topology and resources
allocated, not only in terms of carried traffic.
3. Proposed solution
A new flag in the Administrative Status Object (RFC 3471[4] and RFC
3473 [5]), named Handover flag, is proposed in this memo as a mean to
make possible necessary information exchange among GMPLS enabled
Caviglia et al. Expires - April 2006 [Page 3]
draft-caviglia-mp2cpcp2mp-03 October 2005
nodes, in order to implement and support the functionality introduced
above. The idea is that standard GRSVP-TE signaling flow can be used
to inform nodes about the ownership handover procedure, where such
flow has to be flagged in order to distinguish it from normal LSP
setup/release procedure. When a LSP owned by Management Plane has to
be handed over to Control Plane, a signaling set-up with HANDOVER
flag set has to be sent from ingress node. At ingress node all the
information related to the LSP is passed to GRSVP-TE, which uses it
to fill in the PATH message (Explicit Route Object - ERO, Traffic
Engineering and context information). Such PATH message, sent with
HANDOVER flag set, reaches the nodes along the LSP path and informs
them that the referred LSP is already present at Data Plane level and
that it has to be adopted by Control Plane. After a node has received
such special PATH, it becomes owner of the LSP and treat it like any
other LSP set up via GRSVP-TE. Let's call this procedure "MP to CP
handover".
The opposite procedure "CP to MP handover" works in a similar way.
When a LSP owned by Control Plane has to be handed over to Management
Plane, a signaling PATH DOWN with HANDOVER flag set has to be sent
from ingress node along the LSP path, informing involved nodes that a
CP to MP handover is in progress for that LSP.
The information about that LSP under control within GRSVP-TE scope is
passed to Management Plane at ingress node, and in every node, which
receives flagged PATH DOWN. A node is able to recognize such special
PATH DOWN by reading the handover flag value. If a node finds that
flag set, then it is aware that that the related LSP has to stay
untouched at Data Plane level, but its ownership has to be passed to
Management Plane. It is worth stressing that, when the LSP is adopted
either by CP or MP, i.e. at the end of signaling with Handover flag
set, normal CP procedures or MP procedures have to take their place
as usual when needed. This means that a LSP formerly owned by MP,
signaled within CP with Handover flag set (i.e. handed over to CP)
can be deleted by usual relevant Control Plane signaling flows (i.e.
with Handover flag not set). The same applies when considering the
handover of a LSP from CP to MP when, at the end of procedure, the
LSP belongs to Management Plane and can be fully controlled by NMS.
In other words, after the LSP handover procedures have taken place,
the LSP is not different from the other LSP owned by handover
destination entity and it has to be treated with usual rules for that
entity.
This is in some way similar to the Restart Procedure, (Section 4.3
RFC 3473 [5]), in the sense that the status of the physical resources
at Data Plane has to stay unmodified but the associated information
allowing its control has to be transferred. The modification proposed
in this document refers only to Administrative Status object, that
is, the message flow is left unmodified for both set-up and deletion.
Following section gives detailed description of proposed "MP to CP
handover" and "CP to MP handover" procedures.
Caviglia et al. Expires - April 2006 [Page 4]
draft-caviglia-mp2cpcp2mp-03 October 2005
In the following the handover of a bidirectional LSP is assumed. The
case of unidirectional LSP can be easily derived from that.
4. LSP Ownership Handover Procedure Between Management And Control
Planes
Resv Confirm message within LSP setup signaling flow SHOULD be
supported in order to manage at best LSP Ownership Handover Procedure
Between Control And Management Planes. If Resv Confirm is not present
in message set used for LSP setup, the handover procedure described
below is still applicable using the simple Path/Resv sequence (with
handover flag set as detailed in the following). In that case,
handover related operations that in the following description are
triggered by reception of Resv Confirm, MUST to be executed at the
reception of Resv message.
4.1 "MP to CP handover" - LSP Ownership Transfer From Management Plane
To Control Plane
Let's consider the case of a Data Plane connection between two nodes
acting as ingress and egress for a LSP. Let's assume that Management
Plane has the ownership and control of the LSP and that we want to
hand it over to Control Plane.
At the ingress node NMS initiates the transfer of LSP related
information residing within Management Plane to GRSVP-TE records
within Control Plane. We assume that this happens under operator or
management application control and in particular that:
- Control requests are sent to the ingress LSR by the MP
- The MP has some way of knowing when the CP has completed its task
or has failed.
Ingress node collects from MP all the LSP related information needed
at Control Plane level. The way this operation is done and where such
information is collected within MP is outside the scope of this memo.
A relevant part of such information is represented by the LSP path,
which has to be handed over to CP to be used by signaling entity to
fill the Explicit Route Object (ERO) during setup.
In order to support the MP to CP handover of LSP, the ERO object in
the Path message MUST be filled with all the LSP relevant information
down to the Label level. That can be done by means of the object and
procedures defined in [5].
The precise filling of the ERO object is needed as we are assuming
that the LSP already exists in the network and that every signaling
relevant info about it is available and accessible to MP in terms of
required LSP parameters to build a GRSVP-TE PATH message. After
gathering all the LSP related information, the ingress node sends out
Caviglia et al. Expires - April 2006 [Page 5]
draft-caviglia-mp2cpcp2mp-03 October 2005
a GRSVP-TE PATH message including the Administrative Status Object
with HANDOVER flag set.
Upon reception of such GRSVP-TE PATH, a node MUST be able to
understand that a MP to CP handover procedure is in progress by
reading Handover flag.
Either the ingress node of the LSP (upon request from MP) and
intermediate and egress nodes (when receiving a Path message
containing an Administrative Status object with the Handover flag
set) is informed about the fact that a LSP adoption procedure is
requested or ongoing. The node assumes that a Data Plane resource
related to the info carried in Path Message is already allocated and
in place. The node SHOULD check however the consistence of the actual
Data Plane status of such resource:
- If the check goes OK, then a GRSVP-TE record for the LSP is
created associating it to the corresponding Data Plane state. The
node accepts all the LSP information carried in PATH (if the node
is not ingress of the LSP, otherwise the information is sent from
relevant MP entity) and stores it in Path State Block. After that,
the procedure goes on as described below.
- If the check goes NOT OK, that is actual Data Plane state for the
indicated resource is different from the one indicated in the Path
message, then:
o A PathErr with Path State Removed flag set should be generated
o GMPLS Control Plane state information about it is not accepted
by the handover destination entity
In both cases, no operation is done over Data Plane. In case of
positive check, no change is required at that level since the
connection is already set up and in service. In case of negative
check, a mismatch or some other error has occurred and no LSP control
handover is possible. The procedure rolls back and information
transfer process from MP to CP at ingress node of the LSP has to be
fixed and reinitiated. A node participating in a MP to CP handover
procedure MUST in fact keep track of the special 'handover' condition
of the LSP involved, by retaining handover flag status within GRSVP-
TE records.
This is important because during handover procedure no other Data
Plane, Control Plane or Management Plane action has to be taken on
the LSP outside the control of the procedure itself. Such special
state regarding the involved LSP has to be retained until the
procedure itself has correctly ended.
After propagating handover Path, a node MUST wait for a Resv message
including Administrative Status Object with handover flag set. After
receiving it, the actual migration of LSP information is complete.
Caviglia et al. Expires - April 2006 [Page 6]
draft-caviglia-mp2cpcp2mp-03 October 2005
However, Handover flag is cleared in Path/Resv state block of the
involved LSP, only by reception of ResvConfirm message (or Resv
message, if ResvConfirm is not supported). After the flag is cleared,
the LSP is left completely under control of GRSVP- TE within Control
Plane. This means that any memory about the former MP ownership of
the LSP is lost.
The following example covers all possible MP to CP Handover
scenarios, either in case of success or failure. In the example we
assume that Data Plane connection, whose control and control
information has to be handed over from MP to CP, is TDM based (either
SDH or SONET). A more generic case, where the Data Plane resource
making up the LSP is not tied to a specific technology, can easily be
derived from this one. The table refers to possible cases when a node
at CP level has received LSP information provided by MP and verifies
if handover is feasible.
Let's consider a LSP over the network, connecting a ingress node I
with an egress node E. Let's call timeslot A and B the Data Plane
resources referred by control information involved in Handover in a
given node traversed by the LSP. This means that Handover flagged
signaling refers to A-B cross-connection over Data Plane.
The ingress node initiates the procedure upon request from Management
Plane. The way LSP related information is passed from MP to ingress
node is outside the scope of this procedure description.
Intermediates nodes and egress node receive the request for LSP
adoption and the information needed for the operation from Handover
flagged GRSVP-TE signaling.
The symbol <----> in table below indicates that the two Timeslots
involved in Data Plane cross-connection are actually cross-connected
over Data Plane, hence Data Plane state corresponds to the indication
provided by LSP data held by MP and in the process of being handed
over to CP.
|Actual Data|Control Plane |Management Plane|Data Plane
|Plane State|LSP data record|LSP data record |Resources check
Case 1| A<---->B |No info yet |MP expects A-B |OK to MP to CP
| | | |LSP handover
Case 2| A<---->C |No info yet |MP expects A-B |NOT OK for MP to
| | | |CP LSP handover
Case 1:
- LSP info from Management Plane to be used for LSP control hand
over to GRSVP-TE matches Data Plane state in terms of involved
resources
- LSP data record is not owned yet by Control Plane, hence LSP
control is still up to MP
- Checks are OK, so GRSVP-TE state (related to involved LSP) is
associated to Data Plane state after Handover flagged signaling
flow (Path/Resv/Resv Confirm with Handover flag set) has ended.
Caviglia et al. Expires - April 2006 [Page 7]
draft-caviglia-mp2cpcp2mp-03 October 2005
- At the end of signaling the LSP is completely under CP control.
- No actions are taken in the Data Plane.
Case 2:
- LSP info from Management Plane to be used for LSP control hand
over to GRSVP-TE doesn't match Data Plane state in terms of
involved resources.
- Control Plane does not own LSP data record yet; hence LSP control
is still up to MP.
- Checks are NOT OK. A-B connection is not actually present over
Data Plane and indicated resources are used within other context
(A is x-connected to C).
- GRSVP-TE state (related to involved LSP) is not associated to the
cross connection after Handover flagged Path message.
- A PathErr with Path State Removed flag set MUST be sent Upstream.
- LSP ownership remains completely under MP control. Handover has
failed.
- No actions are taken in the Data Plane.
4.2 MP to CP Handover Procedure Failure Handling
When a mismatch is detected between LSP information owned by MP (and
going to be handed over to CP) and the actual Data Plane state
corresponding to that LSP, actions have to be taken to roll back the
LSP ownership handover correctly.
If such mismatch is detected at LSP ingress node, the issue has to be
resolved directly between ingress node and MP designed entity and
this lies outside the scope of this memo. No Control plane signaling
is involved yet at this stage.
If the mismatch is detected at intermediate or egress nodes, when the
LSP control information arrives at the node via handover flagged Path
message, the node MUST reject it by issuing PathErr with Path State
Removed towards the ingress node. In such a way the procedure is
interrupted at that node, upstream nodes are informed and no changes
are done over control and Data Plane. When a node receives PathErr
with Path State Removed referred to a LSP, whose data record at CP
has handover flag set (being in 'handover state'), it MUST clear such
LSP data record and propagate the PathErr message upstream.
No Data Plane actions have to be taken in this case as well.
The same applies to PathTear message.
4.3 "CP to MP handover" - LSP Ownership Transfer From Control Plane To
Management Plane
Caviglia et al. Expires - April 2006 [Page 8]
draft-caviglia-mp2cpcp2mp-03 October 2005
Let's now consider the case of LSP Ownership Transfer From Control
Plane To Management Plane. The scenario is still a Data Plane
connection between two nodes acting as ingress and egress for a
LSP. But let's assume in this case that Control Plane has the
ownership and control of the LSP and that we want to hand it over
to Management Plane. This means that at the end of such procedure,
the Data Plane state related to that connection is still untouched,
but the LSP related information record is no more owned by GRSVP-TE
over Control Plane.
In other words, after LSP ownership transfer from CP to MP, the LSP
is no more under control of GRSVP-TE, which is no more able to "see"
the LSP itself. This Section covers the procedure needed to manage
this procedure as a dual, opposite procedure respect to the one
described in previous section.
The procedure is performed at a signaling level as described in
Section 7.2.1 of the RFC 3473 [5].
At LSP ingress node, relevant MP entity requests the ownership of the
LSP, How this is done is outside the scope of memo. Ingress node and
MP exchange the relevant information for this task and then
propagates it over Control Plane by means of GRSVP-TE tear down
signaling flow as detailed below.
Ingress node MUST send out a Path Down message, with Handover and
Reflect bits in Admin Status set. No action is taken over Data Plane
and Control Plane keeps track of special handover state the LSP is
in.
Transit and Egress nodes, upon reception of such handover Path Down,
propagate it without any Data Plane action, retaining the handover
state information associated to the LSP. After that, every node waits
until the Handover bit is received back in the Resv. Then a PathTear
is issued and the whole LSP information record is cleared from GRSVP-
TE data structures. In other words, a normal LSP tear down signaling
is exchanged between nodes traversed by the LSP, but handover flag
set in Path Down message indicates that no Data Plane action has to
correspond to Control Plane signaling. At the end of handover tear
down signaling flow, the LSP is released from Control Plane point of
view, but its Data Plane state is still unmodified and it is now
owned and controllable by MP.
4.4 CP to MP Handover Procedure Failure Handling
Failures during CP to MP handover procedure MUST be managed at
signaling level as in normal LSP tear down procedure. The only
difference is the handover flag set in Administrative Status Object
inside Path Down message, which MUST be read by receiving node and
imposes that no action has to be made over Data Plane resource whose
corresponding Control Plane record is involved in handover procedure.
Caviglia et al. Expires - April 2006 [Page 9]
draft-caviglia-mp2cpcp2mp-03 October 2005
5. An Alternative Way Of Doing MP To CP Handover
An alternative way to perform the MP to CP handover is also proposed
in this draft. The rationale behind this way is that only a minimal
set of information is handed over from MP to CP at LSPÆs Ingress
node. Instead of collecting and passing to CP all the LSP relevant
information down to the Label level and formatting it to an ERO, as
in previously described solution, it is possible to start with a
minimum amount of information. At the ingress node, the information
needed to specify the LSP is the outgoing interface ID, upstream
label and downstream label of this interface and the incoming
interface ID of egress node. The remaining information about an
existing LSP can then be collected hop by hop, as the signalling is
going on, by looking up the cross-connection table in data plane at
each node along the LSP path.
Starting from the information available at ingress TNE about the
outgoing interface ID of that ingress node, the incoming interface ID
of next hop can be found by looking up the link resource
table/database in TNE itself. Following the similarity existing
between the MP to CP handover procedure and the Restart Procedure,
the Recovery Label Object MUST be used to carry the downstream label
and the Upstream Label Object MUST be used to carry the upstream
label to the next node.
The Path message is hence built with the Recovery Label Object (RFC
3473[5]) and the Upstream Label Object (RFC 3473[5]), where the
upstream label and downstream label of ingress outgoing interface of
the LSP are included in these two objects. In addition to above
mentioned objects, the Path message MUST include the Administrative
Status Object with HANDOVER flag set, as already defined in previous
chapter for the detailed ERO based way of proceeding. Such handover
Path is sent to the incoming interface of next hop.
When this Path message reaches the second node along the LSP path,
the information about incoming interface ID and the upstream and
downstream labels of this interface is extracted from it and it is
used to find next hopÆs outgoing interface ID and the upstream/
downstream labels by looking up the data plane cross-connection
table. After having determined in this way the parameters describing
the LSPÆs next hop, the outgoing Path message to be sent is built
Caviglia et al. Expires - April 2006 [Page 10]
draft-caviglia-mp2cpcp2mp-03 October 2005
replacing the Recovery Label Object and Upstream Label Object content
with the looked-up values of upstream and downstream labels.
Re-iterating this procedure for each transit node along the LSP path,
it is possible to make the handover Path message reach the egress
node, exactly following the LSP that is in place over data plane.
The ERO MAY in this case be included in the Path message as an
optional object, and MAY be filled with the LSP relevant information
down to either the port level with interface ID or the Label level
with upstream and downstream labels. The ERO can be used to check the
consistence of resource in data plane down to the port level or label
level at each intermediate node along the LSP path.
6. RSVP Message Formats
This memo does not introduce any modification in RSVP messages.
6.1 Object Modification
This memo introduces a new flag into the Administrative Status
object.
The Admin_Status Object is defined in RFC 3473 [5].
This document uses the H-bit of the Admin_Status object. The bit is
bit number (TBD by IANA).
Handover signaling (H): 1 bit
When set, indicates that a Handover procedure for the transfer of LSP
ownership between Management and Control Planes is ongoing .
7. Security Considerations
The procedures described in this document rely completely on GRSVP-TE
messages and mechanism. The use of Handover Flag set in Admin Status
Object basically informs the receiving entity that no operations are
to be done over Data Plane as consequence of such special signaling
flow. Using specially flagged signaling messages we want to limit the
function of setup and tear down messages to Control Plane, making
them not effective over related Data Plane resource usage. So, no
additional or special issues are arisen by adopting this procedure,
that aren't already brought up by the use of the same messages,
without handover flag setting, for LSP control. For GRSVP-TE Security
please refer to [3].
Caviglia et al. Expires - April 2006 [Page 11]
draft-caviglia-mp2cpcp2mp-03 October 2005
8. IANA Consideration
IANA has been asked to manage the bit allocations for the
Administrative Status object [6].
This document requires the allocation of the Handover bit: the H-bit.
IANA is requested to allocate a bit for this purpose.
9. References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
[3] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon
Internet Ltd., November 1997
[4] L. Berger (Ed.) ôGeneralized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Descriptionö, RFC 3471, January 2003
[5] L. Berger (Ed.) ôGeneralized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering
(RSVP-TE) Extensionsö, RFC 3473, January 2003
[6] Zamfir, A., " Component Link Recording and Resource Control for
GMPLS Link Bundles", draft-zamfir-explicit-resource-control-bundle-
03, February 2004 - work in progress.
[7] L. Berger (Ed.) "GMPLS - Communication of Alarm Information",
draft-ietf-ccamp-gmpls-alarm-spec-02.txt, November 2004, work in
progress.
10. Acknowledgments
Adrian Farrel provided editorial assistance to prepare this draft for
publication.
Caviglia et al. Expires - April 2006 [Page 12]
draft-caviglia-mp2cpcp2mp-03 October 2005
Author's Addresses
Diego Caviglia
Marconi
Via A. Negrone 1/A
Genova-Sestri Ponente, Italy
Phone: +390106003738
Email: diego.caviglia@marconi.com
Dino Bramanti
Marconi
Via Moruzzi 1
C/O Area Ricerca CNR
Pisa, Italy
Email: dino.bramanti@marconi.com
Nicola Ciulli
NextWorks
Corso Italia 116
56125 Pisa, Italy
Email: n.ciulli@nextworks.it
Dan Li
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
danli@huawei.com
Tel: +86-755-28972329
Intellectual Property Rights Notices
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.
Caviglia et al. Expires û April 2006 [Page 13]
draft-caviglia-mp2cpcp2mp-03 October 2005
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.
Full Copyright Statement
Copyright (C) The Internet Society (2005). 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.
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.
Caviglia et al. Expires û April 2006 [Page 14]
