[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Review of draft-caviglia-mp2cpcp2mp-01.txt
Hi Adrian,
thank you for your valuable comments.
We'll take them in consideration reviewing the ID, hopefully we'll be able
to present it to Paris if there room for that.
Best Regards
Diego
"Adrian Farrel" <adrian@olddog.co.uk> on 04/06/2005 14.28.37
Please respond to "Adrian Farrel" <adrian@olddog.co.uk>
To: "Diego Caviglia" <Diego.Caviglia@marconi.com>
cc: <ccamp@ops.ietf.org>, <dino.bramanti@marconi.com>,
<n.ciulli@nextworks.it>
Subject: Review of draft-caviglia-mp2cpcp2mp-01.txt
Hi Diego,
I have had a look through your I-D and have a few comments attached.
This could be a nice and useful little function requiring only a very
short document and just one bit on the wire. Excellent!
Wrt your proposed solution, I think it is nearly there, but needs a few
tweaks and there are still a couple of areas to complete.
You also really need to do some work on the English. I known this is hard
(you write better English than I write Italian!), but in order that the
document can be properly reviewed (and hopefully implemented one day) we
have to improve the use of language. What I suggest is that you make the
revisions necessary for the next version and then you get someone to
review the document just to polish the language. I'm sure there would be
volunteers to work with you on this.
Regards,
Adrian
===========
Network Working Group Diego Caviglia
IETF Internet Draft Marconi
Proposed Status: Informational
## Why do you propose this as Informational? Do you not want it to be
## standardized?
## you may even want to flag it as "Updates RFC 3473"
Expires: August 2005 Dino Bramanti
Marconi
Nicola Ciulli
Nextworks
February 2005
GRSVP-TE signaling extension for LSP ownership handover from
Management Plane to Control Plane and vice versa.
## I would prefer the title to be...
## GMPLS Signaling Extensions for the Transfer of Ownership of Label
## Switched Paths Between the Management and Control Planes
draft-caviglia-mp2cpcp2mp-01.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
## You'll need to fix this boilerplate before you republish.
## Don't forget to run the idnis script found at
## http://ietf.levkowetz.com/tools/idnits/
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 (2005). All Rights Reserved.
Abstract
This memo introduces a new flag in the Administrative Status object,
namely the "Handover" flag, and defines its use within GRSVP-TE
signaling. This flag SHOULD be used in order to allow LSPs,
originally created and controlled by the Management Plane (MP), to be
transferred to Control Plane (CP) domain and vice-versa. The result
Caviglia et al. Expires - August 2005 [Page 1]
draft-caviglia-mp2cpcp2mp-02 February 2005
of the Handover flag use in GRSVP-TE is that, at the end of the
setup signaling flow, an LSP that was created thru Management Plane
operations is moved under Control Plane domain and control.
Conversely, at the end of a deletion procedure, the LSP that was
under the Control Plane domain is moved back to the Management Plane
domain.
Both the above procedure are not traffic affecting and can be
performed with "in service traffic".
## It is normal for the Abstract to talk about the problem and the desired
## function rather than solutions.
##
## So you should rephrase this along the lines of...
##
## During migration scenarios it may be desirable to transfer the
## ownership of a Label Switched Path (LSP) from the Management Plane
## to the Control Plane, 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 Multiprotocol
## label Switching (GMPLS) signaling protocol to enable this transfer of
## ownership, and descirbes the necessary 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 [2].
Table of Contents
1. Introduction.....................................................2
2. LSP Adoption/Release.............................................4
2.1 Overview.....................................................4
2.2 LSP Adoption phase: association of GMPLS information to a MP
born LSP - LSP SetUp.........................................4
2.2.1 Association Procedure....................................5
2.2.2 Association Failure Handling.............................6
2.3 LSP Release phase- disassociation of GMPLS information to a
MP born, CP adopted LSP - LSP Tear Down......................7
3. RSVP Message Formats.............................................7
3.1 Object Modification..........................................7
3.1.1 Administrative Status Object.............................7
4. Security Considerations..........................................8
5. IANA Considerations..............................................8
6. Normative References.............................................8
7. Informational References.........................................9
8. Acknowledgements.................................................9
9. Author's Addresses...............................................9
10. Intellectual Property Rights Notices............................9
11. Full Copyright Statement.......................................10
1. Introduction
## I think that before you start you need to explain to the reader that
## when you say "LSP" you mean the data plane forwarding path and data
## plane state. There are many people who have come to use the term
## "LSP" to mean the control plane state necessary to establish and
## maintain the data plane state - of course, you do not mean this.
## You need to expand all of the acronyms the first time they are used
The use of a GMPLS control plane over networks that are already in
service can't be considered of course as a green field application.
This means that in a transport network control scenario LSPs created
and owned by Management Plane and LSPs signaled and owned by means of
GMPLS Control Plane have to coexist. In such a situation it is
possible that a network operator wants to move to Control Plane an
LSP created by and belonging to Management Plane. In a similar
fashion, the opposite operation is also needed. In this memo let's
Caviglia et al. Expires - August 2005 [Page 2]
draft-caviglia-mp2cpcp2mp-02 February 2005
call "LSP adoption" the procedure that is aimed at moving an LSP born
in Management Plane to Control Plane. Let's call "LSP release" the
opposite procedure aimed at moving back the LSP from Control Plane to
Management Plane.
## In fact, it isn't a question of where the LSP was "born" or of
## "moving back". The question is, which plane 'owns' the LSP before and
## after the operation. After all, the LSP could be moved back and
## forwards many times.
##
## I would suggest that "release" is a term already applied to LSP
## teardown, so you should choose another term.
At present there is no way for a Carrier Operator that wants to
associate/disassociate GMPLS information to an already existent LSP.
In particular there is no way to inject LSP information and
visibility from Management Plane to Control Plane (and the other way
back) by means of standard G.RSVP-TE signaling flow.
## Please don't say G.RSVP-TE. It isn't an ITU-T G-series Recommendation
:-)
## You should explain why this does not work for the transfers in both
## directions. For example:
## If you try to signal an LSP to use resources already established and
## under the control of the Management Plane you will either be rejected
## by the network devices because the resources are already in use, or
## you will establish a second, parallel LSP.
## If you try to release an LSP established by the Control Plane by
## sending teardown signaling messages, the LSP will be lost before the
## Management Plane can take over.
##
## You should also explain why make-before-break is not an acceptable
## way to handle this situation. For example, one could have two LSPs
## (one set up by the Management Plane, and one set up by the Control
## Plane) and switch data between them (in the manner of 1+1 protection)
## with no significant hit on the traffic.
A new flag in the Administrative Status Object (RFC 3471[3] and RFC
3473 [4]), named Handover flag, is proposed in this memo as a mean to
make possible necessary information exchange between GMPLS enabled
nodes, in order to implement and support the functionality introduced
above.
Handover flag SHOULD be used during a signaling set-up (tear down,
when performing opposite operation) and allows the association of
LSP-related GMPLS information (at Control Plane level) to a circuit
originated by Management Plane actions and formerly not visible and
"known" to Control Plane itself. Data plane flow related to such LSP
is unaware of this transfer of control from MP to CP (and back). It
is worth taking into account that affected LSP may already be
carrying traffic, which hasn't to be perturbed neither during MP to
CP LSP handover, nor during dual CP to MP control transfer.
The procedure here described is based (in case of MP to CP LSP
handover, for instance) on the collection of information owned by
Management Plane and related to a LSP originated in MP. This detailed
information about route and resources used by the LSP is passed to
Control Plane, which gets it to signal the LSP. When signaling the CP
adopted LSP, Handover flag is set in order to make recognizable that
signal flow and instruct GMPLS nodes about it.
GMPLS nodes have to handle that LSP in such a way that, at the end of
signaling, it is a full effect Control Plane owned LSP.
Conversely, CP to MP migration is signaled over CP by relevant
G.RSVP-TE tear down messages with Handover flag set.
This is in some way similar to the Restart Procedure, (Section 4.3
RFC 3473 [4]), in the sense that the cross connection in the Data
## "cross-connection" throughout the I-D
## The connection has nothing to be cross about :-)
Plane are already present and it is only needed relevant GMPLS
information to be associated to it.
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.
## Most of your description discusses only cross-connections. But of
## course there is more going on in terms of resource reservation and
## resource activation (e.g. turning on lasers). You need to make sure
## that your language cover this.
Caviglia et al. Expires - August 2005 [Page 3]
draft-caviglia-mp2cpcp2mp-02 February 2005
2. LSP Adoption/Release
2.1 Overview
In LSP association/release procedure here introduced, GRSVP-TE
signaling messages and flow is used as normal and the processing of
the messages is exactly the same as usual, except for the fact that
no operation has to be performed over Data Plane. This means that the
cross connection, which is assumed to be physically already in place
in Data Plane, hasn't to be actually created (set-up phase)_ nor
deleted (deletion phase) during signaling flow used to move LSP
control from MP to CP (or CP to MP) .
## This is a major piece of problem statement (that the data plane
## must be unchanged, and that the resources are assumed to be
## already in place). You should move it to section 1.
Such signaling messages are
marked and recognizable for this purpose by Handover flag setting.
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 originated in MP, signaled in CP with Handover flag on and
hence passed to CP, can be deleted by usual and relevant Control
Plane signaling flows (i.e. with Handover flag not set). The same
applies when a LSP belongs to Management Plane. In other words, after
those 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 of that entity.
2.2 LSP Adoption phase: association of GMPLS information to a MP born
LSP - LSP SetUp
In order to support the adoption of a LSP, the ERO object in the Path
message MUST be filled with all the LSP relevant information, that
is, down to the Label level. That can be done by means of the object
and procedures defined in [5].
## You need to reference RFC3209 and RFC3473 here as well.
## But I think that component link identification has become clearer
## since the rework of the bundling I-D and you may be able to reference
## that instead of [5]. Talk to Zafar Ali about that issue.
The filling of the ERO down to the Label Level, including Component
Link identifier when necessary, is possible as we are assuming the
LSP already exists in the Network and the MP has all the associated
information. Management Plane is the entity holding LSP information
and passing it over to CP during adoption.
Signaling set-up related to the LSP adoption contains the Handover
flag of the Administrative State Object set.
Upon reception of GRSVP-TE Path with Handover flagged Admin Status
object, i.e. during signaling set-up, a node SHOULD associate LSP
info at CP level to the existing cross connection.
The information about the fact that a LSP adoption procedure is
ongoing on the LSP should be maintained by the TNE until Resv Confirm
message is received at the node. That information is needed in case
of failures during the association set-up.
Caviglia et al. Expires - August 2005 [Page 4]
draft-caviglia-mp2cpcp2mp-02 February 2005
Resv and Resv Confirm messages following Path (all with Handover flag
set) are processed as usual and, after Resv Confirm processing, the
LSP is completely under the CP domain. This means that any memory
about the fact that previously was under the MP is lost.
## Hmmm. You are assuming the use of the ResvConf message and I am not
## sure that that is a good idea. Why don't you continue to retain this
## information until the Handover flag is cleared?
##
## I think this would work well because, in any case, you need to
## discuss if and when the Handover flag is cleared. Note that
## Admin Status flags are not one-off triggers, but persistent state
## controllers.
##
## Clearing the Handover flag is important because until you have
## doen this, the LSP remains in 'handover state' (that is, it might
## appear to be in the process of being sent back to the MP as
## described in section 2.3) and so the CP will never have full control.
##
## This makes the rules for processing on an LSR very clear:
## When the handover bit is set in the Path state for an LSP, neither
## the CP nor the MP may make changes to the DP state or the associated
## resources. (You would probably want to allow an MP over-ride on this,
## but that is identical to the over-ride that the MP has on a CP-owned
## LSP in normal circumstances.)
Failures during the Adoption of an LSP are managed as usual, except
that TNEs receiving error messages, with Path State Removed set, do
not delete the cross connection in the data plane but only their
GMPLS associated information.
## Well, this ruling applies to all error cases and scenarios.
## That is, while the adoption process is under way (until the ResvConf,
## or clearing of the Handover bit) an LSR MUST NOT release any Data
## Plane state associated with the LSP even if it releases Control
## Plane state.
2.2.1 Association Procedure
## Can you please use RFC2119 terminology in the definition of
## procedures. This will help to remove any ambiguities.
This Section covers the procedure needed to manage a LSP Adoption
procedure, that is, a GRSVP-TE signaling set-up where Path message
contain an Administrative Status object with the Handover flag set.
In the following the adoption of a bidirectional LSP is taken into
consideration. The case of unidirectional LSP can be easily derived
from that.
A node 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 ongoing. The node assumes that a Data Plane
connection related to the info carried in Path Message is already in
place. The node SHOULD check however if there is an actual Data Plane
cross connection between the resources indicated by the message:
- If yes then a GRSVP-TE state is associated with the cross
connection and relevant CP data structures of LSP are created.
- If no, that is the resources are used in a way that is different
from the one indicated by the Path message then:
o a PathErr with Path State Removed flag set should be generated
o GMPLS state information is deleted but actual cross-connection in
## Don't say "GMPLS state information." Say "GMPLS Control Plane state
## information."
the data plane are not.
In order to be able to cope with a failure during described
procedure, the information about the fact that the ongoing signaling
flow is concerning an LSP adoption is maintained by the TNE until the
receipt of the Resv Confirm. In such a way Management Plane holds LSP
related info until Handover flagged signaling session has
successfully ended.
## The previous paragraph highlights that you need to describe (a little
## earlier in the document) how the handover procedure is coordinated
## between the MP and CP. Although the precise mechanisms are out of
## scope, we can assume that:
## - it is under operator or management applicaiton control
## - 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.
The following example illustrates the possible Adoption cases either
successful or failed.
Caviglia et al. Expires - August 2005 [Page 5]
draft-caviglia-mp2cpcp2mp-02 February 2005
The cross connection to be moved under the control plane involves
Timeslot A and B. This means that Handover flagged signaling refers
## You say "Timeslot." Does this only apply to TDM?
to A-B xconnection over Data Plane. The symbol <----> means that the
two Timeslots are actually cross connected over Data Plane.
| Data Plane| Control Plane| Management Plane| Notes
---------------------------------------------------------------------
Case 1 | A<---->B | No info yet | LSP info present| OK for MP to CP
| | | | LSP handover
---------------------------------------------------------------------
Case 2 | A<---->C | No info yet | LSP info present| NOK for MP to
| CP LSP handover
---------------------------------------------------------------------
## Perhaps instead of "LSP info present" for the MP, you should say
## "MP expects A-B".
Case 1:
- LSP info in Management Plane is present and describes A-B
connection.
- LSP is not visible yet over Control Plane.
- A-B connection is actually present over Data Plane.
- GRSVP-TE state (related to involved LSP) is associated to the
cross connection after Handover flagged signaling flow
(Path/Resv/resvConfirm with Handover flag set).
- No actions are taken in the Data Plane.
- At the end LSP is completely under CP control.
Case 2:
- LSP info in Management Plane is present and describes A-B
connection.
- LSP is not visible yet over Control Plane.
- A-B connection is not actually present over Data Plane and relevant
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 signaling flow.
- A PathErr with Path State Removed flag set should be sent Upstream.
- No actions are taken in the Data Plane.
- At the end LSP stays completely under MP control as before.
2.2.2 Association Failure Handling
When a node receives a PathErr with Path State Removed checks if the
LSP it refers to is involved in an Adoption procedure, whose track is
kept until successful end of signaling flow has been carried on as
stated above. If yes, then no actions are performed over the data
plane, while GMPLS status information about involved LSP over Control
Plane is deleted and the cross connection ownership is moved back
under the NMS controls.
Caviglia et al. Expires - August 2005 [Page 6]
draft-caviglia-mp2cpcp2mp-02 February 2005
The same applies for PathTear message.
## Ah. Very important!
## In fact, rather than limiting to the PathErr with PSR flag, and
## PathTear, why don't you say that "While the Handover flag is set in
## the Administrative Status object of the associated Path message, an
## LSR MUST NOT make changes to the data plane state (resource
## reservations, cross-connects, etc.) as the result of either Control
## Plane or Management Plane actions.
2.3 LSP Release phase- disassociation of GMPLS information to a MP born,
CP adopted LSP - LSP Tear Down
This Section covers the procedure needed to manage a LSP Release
procedure (as a dual, opposite procedure respect to Adoption
described above).
Such a procedure is performed at a signaling level as described in
Section 7.2.1 of the RFC 3473 [4]. LSP tear down flow is carried on
as usual, except that Handover flag is set in Administrative Status
Object like it was during set-up (adoption) case.
## Although this reference is correct, I think you could usefully give
## some hints. That is, explain that the procedures are the same as for
## alarm-free teardown using the Adminastrative Status object as
## described in...
Nodes receiving G.RSVP-TE tear down messages with Handover flag set,
## No, no, no, no!
## There is no Admin Status object on a PathTear. Go back and read the
## reference you cited! What you have to do is:
##
## 1. Turn on Handover and Refelect bits in Admin Status on a Path
## 2. Wait until the Handover bit is received back in the Resv
## 3. Send PathTear to release the CP state.
## 4. Apply the same rule as above. That is:
## While the Handover flag is set in
## the Administrative Status object of the associated Path message,
## an LSR MUST NOT make changes to the data plane state (resource
## reservations, cross-connects, etc.) as the result of either
## Control Plane or Management Plane actions.
have to process such messages as usual, but they have to behave in a
special way respect to Data Plane. As a perfect dual situation of the
Adoption described before, no actions at all have to be performed
over the data plane. This means that the node has to carry on tear
down signaling procedure but it SHOULD NOT clear x-connection related
to affected LSP. As a consequence of the Release only GMPLS state
information have to be deleted.
At the end of the Disassociation procedure the GMPLS associated
information is deleted and the LPS is moved under the NMS control.
## You need to add sections to describe:
## - Control Plane failure and recovery during handover
## - Non-support of the handover process by transit or egress LSRs
3. RSVP Message Formats
This memo does not introduce any modification in RSVP messages.
3.1 Object Modification
This memo introduces a new flag into the Administrative Status
object.
3.1.1 Administrative Status Object
## Say...
## The Admin_Status Object is defined in RFC 3473 [4].
##
## This document uses the H-bit of the Admin_Status object. The bit
## is bit number (TBD by IANA).
##### START DELETE
# The use of the Admin_Status Object is optional. It uses Class-Number
# 196 (of form 11bbbbbb).
#
# The format of the Admin_Status Object is:
#
# 0 1 2 3
# 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
# +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
# | Length | Class-Num(196)| C-Type (1) |
# +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
# |R| Reserved |H|L|I|C|T|A|D|
# +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
#
#
#Caviglia et al. Expires - August 2005 [Page 7]
#
#draft-caviglia-mp2cpcp2mp-02 February 2005
#
# Reflect (R): 1 bit
#
# When set, indicates that the edge node SHOULD reflect the
# object/TLV back in the appropriate message. This bit MUST NOT
# be set in state change request, i.e., Notify, messages.
#
# Reserved: 28 bits
#
# This field is reserved. It MUST be set to zero on transmission
# and MUST be ignored on receipt. These bits SHOULD be pass
# through unmodified by transit nodes.
####### END DELETE
Handover signaling (H): 1 bit
When set, indicates that an Association/Disassociation
procedure is ongoing.
## Why not call this the ahndover procedure?
####### START DELETE
# The other flag are defined in the following documents:
# R-bit [RFC3471]
# L-bit [E2E]
# I-bit [ALARM]
# C-bit [ASON]
# T-bit [RFC3471]
# A-bit [RFC3471]
# D-bit [RFC3471]
#
#
# Where:
# [RFC3471] RFC3471
# [E2E] draft-ietf-ccamp-gmpls-recovery-e2e-signaling
# [ALARM] draft-ietf-ccamp-gmpls-alarm-spec
# [ASON] draft-ietf-ccamp-gmpls-rsvp-te-ason
####### END DELETE
4. Security Considerations
This document does not introduce any additional Security issues. For
GRSVP-TE Security please refer to [3].
## I think that the removal of an LSP from one sphere of control to
## another is a serious security issue. You need to explain this risk
## and state why it is or is not a problem.
5. IANA Consideration
This memo introduces a new GRSVP-TE object type and a new Error Code
Error Value couple.
##
## Hmmm? What new object type? What new error code/value?
##
## Say the following...
## 6.1 Administrative Status Bit Allocation
##
## 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. See section
## 3.1.1.
6. Normative 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.
Caviglia et al. Expires - August 2005 [Page 8]
draft-caviglia-mp2cpcp2mp-02 February 2005
3 Berger, L., " Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Functional Description", RFC 3471, January 2003
4 Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Resource ReserVation Protocol-Traffic Engineering
(RSVP-TE) Extensions", RFC 3473, January 2003.
7. Informational References
5 Zamfir, A., " Component Link Recording and Resource Control for
GMPLS Link Bundles",
draft-zamfir-explicit-resource-control-bundle-03, February 2004.
## state "work in progress"
## 6 L. Berger (Ed.) "GMPLS - Communication of Alarm Information",
draft-ietf-ccamp-gmpls-alarm-spec-02.txt, November 2004, work in
progress.
8. Acknowledgements
Adrian Farrel provided editorial assistance to prepare this draft
for publication.
9. Author's Addresses
Diego Caviglia
Marconi
Via A. Negrone 1/A
Phone: +390106003738
Email: diego.caviglia@marconi.com
Dino Bramanti
Marconi
Via Moruzzi 1
C/O Area Ricerca CNR, Pisa
Email: dino.bramanti@marconi.com
Nicola Ciulli
Nextworks
Corso Italia n. 116,
56125 Pisa (Italy)
Email: n.ciulli@nextworks.it
10. 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.
Caviglia et al. Expires - August 2005 [Page 9]
draft-caviglia-mp2cpcp2mp-02 February 2005
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.
11. 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 - August 2005 [Page 10]