draft-ietf-ccamp-pc-and-sc-reqs-03.txt   draft-ietf-ccamp-pc-and-sc-reqs-04.txt 
Network work group Diego Caviglia
Network Working Group Diego Caviglia
Internet Draft Dino Bramanti Internet Draft Dino Bramanti
Ericsson Ericsson
Dan Li Dan Li
Huawei Huawei
Dave McDysan Dave McDysan
Verizon Verizon
Intended Status: Informational Intended Status: Informational
Expires: November, 19 2008 May 19, 2008 Expires: November, 19 2008 May 19, 2008
Requirements for the Conversion Between Permanent Connections and Requirements for the Conversion Between Permanent Connections and
Switched Connections in a Generalized Multiprotocol Label Switching Switched Connections in a Generalized Multiprotocol Label Switching
(GMPLS) Network (GMPLS) Network
draft-ietf-ccamp-pc-and-sc-reqs-03.txt draft-ietf-ccamp-pc-and-sc-reqs-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is 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 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 becomes aware will be disclosed, in accordance with Section 6 of
BCP 79. BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 2, line 23 skipping to change at page 2, line 26
Generalized Multiprotocol Label Switching (GMPLS) network. Generalized Multiprotocol Label Switching (GMPLS) network.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119]. document are to be interpreted as described in RFC-2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction.................................................3 1. Introduction..................................................3
2. Motivation...................................................3 2. Motivation....................................................3
3. Label Switched Path Terminology..............................4 3. Label Switched Path Terminology...............................4
4. LSP within GMPLS Control Plane...............................4 4. LSP within GMPLS Control Plane................................4
4.1. Resource Ownership......................................4 4.1. Resource Ownership.......................................4
4.2. Setting Up a GMPLS Controlled Network...................5 4.2. Setting Up a GMPLS Controlled Network....................5
5. Typical Use Cases............................................6 5. Typical Use Cases.............................................6
5.1. PC to SC/SPC Conversion.................................6 5.1. PC to SC/SPC Conversion..................................6
5.2. SC to PC Conversion.....................................7 5.2. SC to PC Conversion......................................7
6. Requirements.................................................7 6. Requirements..................................................7
6.1. Data Plane LSP Consistency..............................7 6.1. Data Plane LSP Consistency...............................7
6.2. No Disruption of User Traffic...........................7 6.2. No Disruption of User Traffic............................7
6.3. Transfer from Management Plane to Control Plane.........8 6.3. Transfer from Management Plane to Control Plane..........7
6.4. Transfer from Control Plane to Management Plane.........8 6.4. Transfer from Control Plane to Management Plane..........7
6.5. Synchronization of state among nodes during conversion..8 6.5. Synchronization of state among nodes during conversion...8
6.6. Support of Soft Permanent Connections...................8 6.6. Support of Soft Permanent Connections....................8
6.7. Failure of Transfer.....................................8 6.7. Failure of Transfer......................................8
7. Security Considerations......................................8 7. Security Considerations.......................................8
8. IANA Considerations..........................................9 8. IANA Considerations...........................................9
9. References...................................................9 9. References....................................................9
9.1. Normative References....................................9 9.1. Normative References.....................................9
9.2. Informative References..................................9 9.2. Informative References...................................9
10. Acknowledgments.............................................9 10. Acknowledgments..............................................9
11. Authors' Addresses.........................................10 11. Authors' Addresses...........................................9
12. Full Copyright Statement...................................11 12. Full Copyright Statement....................................10
13. Intellectual Property Statement............................11 13. Intellectual Property Statement.............................11
1. Introduction 1. Introduction
In a typical, traditional transport network scenario, Data Plane In a typical, traditional transport network scenario, Data Plane
connections between two end-points are controlled by means of a connections between two end-points are controlled by means of a
Network Management System (NMS) operating within the Management Plane Network Management System (NMS) operating within the Management Plane
(MP). The NMS/MP is the owner of such transport connections, being (MP). The NMS/MP is the owner of such transport connections, being
responsible of their setup, teardown, and maintenance. Provisioned responsible of their setup, teardown, and maintenance. Provisioned
connections of this kind, initiated and managed by the Management connections of this kind, initiated and managed by the Management
Plane, are known as Permanent Connections (PCs) [G.8081]. Plane, are known as Permanent Connections (PCs) [G.8081].
skipping to change at page 4, line 23 skipping to change at page 4, line 21
It defines the forwarding or switching operations at each network It defines the forwarding or switching operations at each network
entity. It is the sequence of Data Plane resources (links, labels, entity. It is the sequence of Data Plane resources (links, labels,
cross-connects) that achieves end-to-end data transport. cross-connects) that achieves end-to-end data transport.
In the Management Plane, an LSP is the management state information In the Management Plane, an LSP is the management state information
(such as the connection attributes and path information) associated (such as the connection attributes and path information) associated
with and necessary for the creation and maintenance of a Data Plane with and necessary for the creation and maintenance of a Data Plane
connection. connection.
In the Control Plane, an LSP is the Control Plane state information In the Control Plane, an LSP is the Control Plane state information
(such as RSVP-TE [RFC3473] Path and Resv state) associated with and necessary for the (such as RSVP-TE [RFC3473] Path and Resv state) associated with and
creation and maintenance of a Data Plane connection. necessary for the creation and maintenance of a Data Plane
connection.
A Permanent Connection has an LSP presence in the Data Plane and the A Permanent Connection has an LSP presence in the Data Plane and the
Management Plane. A Switched Connection has an LSP presence in the Management Plane. A Switched Connection has an LSP presence in the
Data Plane and the Control Plane. An SPC has LSP presence in the Data Data Plane and the Control Plane. An SPC has LSP presence in the Data
Plane for its entire length, but has Management Plane presence for Plane for its entire length, but has Management Plane presence for
part of its length and Control Plane presence for part of its length. part of its length and Control Plane presence for part of its length.
In this document, when we talk about the LSP conversion between In this document, when we talk about the LSP conversion between
Management Plane and Control Plane, we mainly focus on the conversion Management Plane and Control Plane, we mainly focus on the conversion
of Control Plane state information and Management Plane state of Control Plane state information and Management Plane state
information. information.
4. LSP within GMPLS Control Plane 4. LSP within GMPLS Control Plane
Generalized Multiprotocol Label Switching (GMPLS) [RFC3471], [RFC3473] [RFC3945] Generalized Multiprotocol Label Switching (GMPLS) [RFC3471],
defines a powerful Control Plane architecture for transport [RFC3473], [RFC3945] defines a powerful Control Plane architecture
networks. This includes both routing and signaling protocols for the for transport networks. This includes both routing and signaling
creation and maintenance of Label Switched Paths (LSPs) in networks protocols for the creation and maintenance of Label Switched Paths
whose Data Plane is based on different technologies such as TDM (LSPs) in networks whose Data Plane is based on different
(SDH/SONET G.709 at ODUk level) transport and WDM (G.709 OCh level). technologies such as TDM (SDH/SONET G.709 at ODUk level) transport
and WDM (G.709 OCh level).
4.1. Resource Ownership 4.1. Resource Ownership
A resource used by an LSP is said to be 'owned' by the plane that was A resource used by an LSP is said to be 'owned' by the plane that was
used to set up the LSP through that part of the network. Thus, all used to set up the LSP through that part of the network. Thus, all
the resources used by a Permanent Connection are owned by the the resources used by a Permanent Connection are owned by the
Management Plane, and all the resources used by a Switched Connection Management Plane, and all the resources used by a Switched Connection
are owned by the Control Plane. The resources used by an SPC are are owned by the Control Plane. The resources used by an SPC are
divided between the Management Plane (for the resources used by the divided between the Management Plane (for the resources used by the
permanent connection segments at the edge of the network) and the permanent connection segments at the edge of the network) and the
skipping to change at page 8, line 18 skipping to change at page 8, line 8
Management Plane to the Control Plane Management Plane to the Control Plane
6.4. Transfer from Control Plane to Management Plane 6.4. Transfer from Control Plane to Management Plane
It SHOULD be possible to transfer the ownership of an LSP from the It SHOULD be possible to transfer the ownership of an LSP from the
Control Plane to the Management Plane. Control Plane to the Management Plane.
6.5. Synchronization of State Among Nodes During Conversion 6.5. Synchronization of State Among Nodes During Conversion
It MUST be assured that the state of the LSP is synchronized among It MUST be assured that the state of the LSP is synchronized among
all nodes traversed by it before the conversion in considered complete. all nodes traversed by it before the conversion in considered
complete.
6.6. Support of Soft Permanent Connections 6.6. Support of Soft Permanent Connections
It MUST be possible to segment an LSP such that it is converted to or It MUST be possible to segment an LSP such that it is converted to or
from an SPC. from an SPC.
6.7. Failure of Transfer 6.7. Failure of Transfer
It MUST be possible for a transfer from one plane to the other to It MUST be possible for a transfer from one plane to the other to
fail in a non-destructive way leaving the ownership unchanged and fail in a non-destructive way leaving the ownership unchanged and
skipping to change at page 11, line 27 skipping to change at page 11, line 11
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE. FOR A PARTICULAR PURPOSE.
13. Intellectual Property Statement 13. Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed to
to pertain to the implementation or use of the technology described pertain to the implementation or use of the technology described in
in this document or the extent to which any license under such this document or the extent to which any license under such rights
rights might or might not be available; nor does it represent that might or might not be available; nor does it represent that it has
it has made any independent effort to identify any such rights. made any independent effort to identify any such rights. Information
Information on the procedures with respect to rights in RFC on the procedures with respect to rights in RFC documents can be
documents can be found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use attempt made to obtain a general license or permission for the use of
of such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository at
at http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
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".
 End of changes. 10 change blocks. 
49 lines changed or deleted 53 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/