Network work group Fatai Zhang
Internet Draft Dan Li
Intended status: Informational Jianhua Gao
Expires: September 2009 Huawei
March 02, 2009
Requirements for PCE applied
in Time-Division Multiplexing (TDM) Networks
draft-zhang-pce-reqs-for-tdm-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 02, 2009.
Abstract
This document describes the special requirements for applying the
Path Computation Element (PCE) in Time-Division Multiplexing (TDM)
networks, including Synchronous Optical Network (SONET), Synchronous
Digital Hierarchy (SDH), and Digital Wrapper (G.709 ODUk).
The material presented in this document is collected here
for analysis. The intention is to separate this material into
separate documents on generic GMPLS requirements, generic
GMPLS extensions, and TDM-specific requirements and extensions.
Zhang Expires September 2009 [Page 1]
Internet-Draft draft-zhang-PCE-reqs-for-TDM-00.txt March 2009
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 [RFC2119].
Table of Contents
1. Introduction..................................................2
1.1. Disposition of this Document.............................3
2. Terminology...................................................4
3. PCE Applications..............................................4
4. Requirements..................................................5
4.1. Requirements when PCC Specifies the Connection Type......5
4.2. Requirements when PCE Determines the Connection Type.....6
5. Security Considerations.......................................7
6. IANA Considerations...........................................7
7. Acknowledgments...............................................7
8. References....................................................7
9. Authors' Addresses............................................8
1. Introduction
As defined in [RFC4655], a Path Computation Element (PCE) is an
entity that is capable of computing a network path or route based on
a network graph, and of applying computational constraints during the
computation. Any node in the network can act as a Path Computation
Client (PCC) and request PCE to compute a path that satisfies the set
of constraints. When it finishes computing, the PCE will respond with
the path to the PCC. The communication protocol between PCE and PCC
has been described in [PCEP].
The main work for PCE so far has been its application in MPLS
networks that are already stable and mature. However, the application
of PCE to GMPLS in packet and non-packet networks has also been
considered. GMPLS has more technology-specific and generic traffic
engineering constraints, and some of these, for TDM networks, need
further extensions to PCEP.
First, the properties of the LSP being computed should be fed to the
PCE from the PCC. These properties include the switching capabilities
(e.g., TDM, lambda, LSC, etc.), the encoding type (e.g., SDH/Sonet,
Digital Wrapper, lambda, etc.), and the signaling type (e.g., VC12,
VC3, ODUk, etc.). This information is very important for the PCE to
zhang Expires September 2009 [Page 2]
Internet-Draft draft-zhang-PCE-reqs-for-TDM-00.txt March 2009
compute a required Path. These properties are parameters are added to
PCEP in [PCEP-Layer].
Second, the reliability of the network is very important for
transport networks. So the PCE should get information about required
level of protection for the LSP from the PCC. In TDM networks, there
are abundant protection types to satisfy different demand for the
service, for example, 1+1 protection, 1:1 protection, 1: n protection,
full rerouting, shared-mesh restoration, and segment recovery, etc.
This information is really important for PCE to compute the
corresponding work LSP and protection LSP correctly on operating the
traffic engineering database (TED). In addition, the link protection
also should be taken into account for PCE path computation. The
requirements for LSP protection type and link protection type are
addressed briefly in [PCE-App-Req].
Third, in TDM networks (e.g., SDH/OTN networks), a client service can
be transmitted by various connection(s) of TDM with different
connection type. For example, in the SDH networks, if the client
service which is 100M Ethernet is required to be transported over the
SDH networks, the Ethernet service can be provided by a VC4
connection, and it can also be provided by three concatenated VC3
connections (Contiguous or Virtual Concatenation). So this
information about connection type is vital for PCE to compute the
correct LSP(s) to transport the service traffic.
The above three requirements are very important for PCE to compute
the desirable paths when PCE applied in the TDM networks. However,
the first two requirements are addressed partially in [PCEP-Layer] and
[PCE-App-Req], so this document focuses on the third requirement.
1.1. Disposition of this Document
The material presented in this document is collected here for
analysis. The intention is to separate this material into separate
documents as follows:
- Generic GMPLS requirements for PCEP will be merged into a single
document working with the authors of [PCE-App-Req].
- A new document will be created to provide generic GMPLS
extensions to PCEP to address the generic requirements.
- This document will be reduced to contain the TDM-specific
requirements (If needed, we can use one document to cover the
zhang Expires September 2009 [Page 3]
Internet-Draft draft-zhang-PCE-reqs-for-TDM-00.txt March 2009
TDM-specific requirements and extensions).
2. Terminology
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 [RFC2119].
3. PCE Applications
The TDM networks are usually responsible for transmitting data for
the client layer. These TDM networks can provide different types of
connections for customer services based on different service
bandwidth requests.
The applications and the corresponding additional requirements for
applying PCE in TDM networks are described below. In order to
simplify the description, this document just discusses the scenario
in SDH networks as an example. The scenarios in SONET or G.709 ODUk
layer networks are similar.
+------+ +------+ +------+
| | | | | |
A1--| N1 +------------------+ N2 | | PCE |
| | | | | |
+--+---+ +---+--+ +------+
| \ |
| \ +------+ |
| | | |
| | N5 | |
| | | |
| +------+ \ |
+--+---+ \ +---+--+
| | | |
| N4 +------------------+ N3 |--A3
| | | |
+------+ +------+
Figure 1: A simple SDH network
Figure 1 shows a simple network topology, where N1, N2, N3, N4, and
N5 are all SDH switches. Assume that one Ethernet service with 100M
zhang Expires September 2009 [Page 4]
Internet-Draft draft-zhang-PCE-reqs-for-TDM-00.txt March 2009
bandwidth is required from A1 to A3 over this network. The client
Ethernet service could be provided by a VC4 connection from N1 to N3,
and it could also be provided by three concatenated VC3 connections
(Contiguous or Virtual concatenation) from N1 to N3.
The type of connectivity that is required (one VC4 or three
concatenated VC3) needs to be specified by PCC (e.g., N1 or NMS), but
could also be determined by PCE automatically based on policy,
configuration, or network capabilities. This is related to the
policies which can be implemented per [RFC5394]. The next section
lists requirements described according to different the policies that
are applied.
4. Requirements
4.1. Requirements when PCC Specifies the Connection Type
In this case, when receiving the service request from A1 to A3 from
client layer, the PCC (e.g., N1) specifies the transport scheme for
the service based on the requested bandwidth and the transport
policies pre-configured, and then requests the PCE to compute the
corresponding path. For example, the node N1 specifies that it needs
three virtual concatenated VC3 connections in the Path Computation
Request message to the PCE. Therefore, the following information
should be specified by PCC in the PCReq message:
(1) Signal Type: Indicates the type of elementary signal that
constitutes the requested LSP. A lot of signal types with
different granularity have been defined in SONET/SDH and G.709
ODUk, such as VC11, VC12, VC2, VC3 and VC4 in SDH, and ODU1,
ODU2 and ODU3 in G.709 ODUk. See [RFC4606] and [RFC4328] (Note
that switching capability and encoding type should also be
specified which are described in [PCE-App-Req]).
(2) Concatenation Type: In SDH/ SONET and G.709 ODUk networks, two
kinds of concatenation modes are defined: contiguous
concatenation which requires co-router for each member signal
and requires all the interfaces along the path to support this
capability, and virtual concatenation which allows diverse
routes for the member signals and only requires the ingress and
egress interfaces to support this capability. Note that for the
virtual concatenation, it also may specify co-routed or
separated-routed. See [RFC4606] and [RFC4328] about
Concatenation information.
zhang Expires September 2009 [Page 5]
Internet-Draft draft-zhang-PCE-reqs-for-TDM-00.txt March 2009
(3) Concatenation Number: Indicates the number of signals that are
requested to be contiguously or virtually concatenated. Also see
[RFC4606] and [RFC4328].
When receiving the PCReq message, PCE computes the path that
satisfies the set of constraints in the PCReq message. If successful,
the corresponding path will be returned to PCC in the PCRep message.
Note that the PCE should return the above information (Signal type,
Concatenation type, Concatenation number) in the PCRep message to
tell PCC how to create the corresponding connections.
In the case of virtual concatenation, when separate-routed paths are
required, it is necessary for the PCE to indicate that how many
member signals are needed in each route. For example, in Figure 1, if
the node N1 requests a virtual concatenation connection with four VC4
signals and these four VC4 member signals should be separated-routed,
the result of path computation may be two VC4 signals along the route
N1-N2-N3 and another two VC4 signal along the route N1-N5-N3.
4.2. Requirements when PCE Determines the Connection Type
In this case, when receiving the request for a service from A1 to A3
from the client layer, the PCC (e.g., N1) sends the PCReq message to
the PCE. The message contains the information about requested
bandwidth, as described in [PCEP].
When receiving the PCReq message, the PCE determines the transport
scheme for the service based on the requested bandwidth and the pre-
configured transport policies, and then computes the path. If
successful, the information of the corresponding paths will be sent
to the PCC in the PCRep message.
In order that the PCC can set up the corresponding path, the PCE
should tell the PCC the transport scheme, i.e., the connection type.
So the PCRep message should contain the information described below:
(1) Signal Type: Same as described in Section 4.1.
(2) Concatenation Type: Same as described in Section 4.1.
(3) Concatenation Number: Same as described in Section 4.1.
In the case of virtual concatenation when separated routed paths are
returned, it is also necessary for the PCE to indicate that how many
zhang Expires September 2009 [Page 6]
Internet-Draft draft-zhang-PCE-reqs-for-TDM-00.txt March 2009
member signals are needed in each route, which is the same as
described in Section 4.1.
5. Security Considerations
This document just focuses on the requirements when PCE is applied in
the TDM networks, so there is no additional security introduced.
Possible security issues should be considered when it need extend
PCEP to support these requirements.
6. IANA Considerations
There is no IANA request in this document.
7. Acknowledgments
TBD.
8. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[PCEP] JP. Vasseur et al, "Path Computation Element (PCE)
communication Protocol (PCEP) - Version 1 -" draft-ietf-
pce-pcep (work in progress).
[PCE-App-Req] Tomohiro Otani, Kenichi Ogaki and Diego Caviglia,
"Requirements for GMPLS applications of PCE" draft-ietf-
pce-gmpls-aps-req-00 (work in progress).
[RFC4655] A. Farrel, JP. Vasseur and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, September 2006.
[RFC4657] J. Ash and J.L. Le Roux, "Path Computation Element (PCE)
Communication Protocol Generic Requirements", RFC 4657,
September 2006.
[RFC4606] E. Mannie and D. Papadimitriou, "GMPLS extensions for SONET
and SDH control", RFC 4606, August 2006.
[RFC4328] D. Papadimitriou, "GMPLS Signaling Extensions for G.709
Optical Transport Networks Control", RFC 4328, January 2006.
[RFC5394] I. Bryskin, D. Papadimitriou, L. Berger and J. Ash,
"Policy-Enabled Path Computation Framework", RFC 5394,
December 2008.
zhang Expires September 2009 [Page 7]
Internet-Draft draft-zhang-PCE-reqs-for-TDM-00.txt March 2009
[PCEP-Layer] E. Oki, T. Takeda, J-L. Le Roux, and A. Farrel,
"Extensions to the Path Computation Element communication
Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic
Engineering", draft-ietf-pce-inter-layer-ext, work in
progress.
9. Authors' Addresses
Fatai Zhang
Huawei Technologies Co., Ltd.
F3-5-B R&D Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129 P.R.China
Phone: +86-755-28972912
Email: Zhangfatai@huawei.com
Dan Li
Huawei Technologies Co., Ltd.
F3-5-B R&D Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129 P.R.China
Phone: +86-755-28973237
Email: danli@huawei.com
Jianhua Gao
Huawei Technologies Co., Ltd.
F3-5-B R&D Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129 P.R.China
Phone: +86-755-28972912
Email: gjhhit@huawei.com
Intellectual Property
The IETF Trust 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 any IETF Document or the extent to which any license
zhang Expires September 2009 [Page 8]
Internet-Draft draft-zhang-PCE-reqs-for-TDM-00.txt March 2009
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.
Copies of Intellectual Property 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
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
The definitive version of an IETF Document is that published by, or
under the auspices of, the IETF. Versions of IETF Documents that are
published by third parties, including those that are translated into
other languages, should not be considered to be definitive versions
of IETF Documents. The definitive version of these Legal Provisions
is that published by, or under the auspices of, the IETF. Versions of
these Legal Provisions that are published by third parties, including
those that are translated into other languages, should not be
considered to be definitive versions of these Legal Provisions.
For the avoidance of doubt, each Contributor to the IETF Standards
Process licenses each Contribution that he or she makes as part of
the IETF Standards Process to the IETF Trust pursuant to the
provisions of RFC 5378. No language to the contrary, or terms,
conditions or rights that differ from or are inconsistent with the
rights and licenses granted under RFC 5378, shall have any effect and
shall be null and void, whether published or posted by such
Contributor, or included with or in such Contribution.
Disclaimer of Validity
All IETF Documents and the information contained therein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST 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 THEREIN WILL NOT INFRINGE
zhang Expires September 2009 [Page 9]
Internet-Draft draft-zhang-PCE-reqs-for-TDM-00.txt March 2009
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Full Copyright Statement
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
zhang Expires September 2009 [Page 10]