draft-ietf-pce-gmpls-aps-req-03.txt   draft-ietf-pce-gmpls-aps-req-04.txt 
Network Working Group Tomohiro Otani Network Working Group Tomohiro Otani
Internet Draft KDDI Internet Draft KDDI
Intended status: Informational Kenichi Ogaki Intended status: Informational Kenichi Ogaki
KDDI R&D Labs KDDI R&D Labs
Diego Caviglia Diego Caviglia
Ericsson Ericsson
Fatai Zhang Fatai Zhang
Huawei Huawei
Expires: April 20, 2011 October 20, 2010
Expires: November 30, 2011 May 30,2011
Requirements for GMPLS applications of PCE Requirements for GMPLS applications of PCE
Document: draft-ietf-pce-gmpls-aps-req-03.txt Document: draft-ietf-pce-gmpls-aps-req-04.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 20, 2011. This Internet-Draft will expire on November 30, 2011.
Abstract Abstract
The initial effort of PCE WG is specifically focused on MPLS (Multi- The initial effort of PCE WG is specifically focused on MPLS (Multi-
protocol label switching). As a next step, this draft describes protocol label switching). As a next step, this draft describes
functional requirements for GMPLS (Generalized MPLS) application of functional requirements for GMPLS (Generalized MPLS) application of
PCE (Path computation element). PCE (Path computation element).
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 [RFC2119]. document are to be interpreted as described in [RFC2119].
Table of Contents Table of Contents
1. Introduction.................................................2 1. Introduction ................................................ 2
2. Terminology..................................................3 2. Terminology ................................................. 3
3. GMPLS applications of PCE....................................3 3. GMPLS applications of PCE.................................... 3
3.1. GMPLS network model.....................................3 3.1. GMPLS network model..................................... 3
3.2. Path computation in GMPLS network.......................4 3.2. Path computation in GMPLS network .......................4
3.3. Unnumbered Interface....................................5 3.3. Unnumbered Interface.................................... 6
3.4. Asymmetric Bandwidth Path Computation...................6 3.4. Asymmetric Bandwidth Path Computation ...................6
4. Requirements for GMPLS application of PCE....................6 4. Requirements for GMPLS applications of PCE ...................6
4.1. Requirements of Path Computation Request................6 4.1. Requirements of Path Computation Request ................6
4.2. Requirements of Path Computation Reply..................7 4.2. Requirements of Path Computation Reply ..................7
4.3. GMPLS PCE Management....................................8 4.3. GMPLS PCE Management.................................... 8
5. Security consideration.......................................8 5. Security consideration....................................... 8
6. IANA Considerations..........................................8 6. IANA Considerations ......................................... 9
7. Acknowledgement..............................................8 7. Acknowledgement ............................................. 9
8. References...................................................8 8. References .................................................. 9
9. Authors' Addresses..........................................10 9. Authors' Addresses ......................................... 11
1. Introduction 1. Introduction
The initial effort of PCE WG is focused on solving the path The initial effort of PCE WG is focused on solving the path
computation problem over different domains in MPLS networks. As the computation problem over different domains in MPLS networks. As the
same case with MPLS, service providers (SPs) have also come up with same case with MPLS, service providers (SPs) have also come up with
requirements for path computation in GMPLS networks such as photonics, requirements for path computation in GMPLS networks such as photonics,
TDM-based or Ethernet-based networks as well. TDM-based or Ethernet-based networks as well.
[PCE-ARCH] and [PCECP-REQ] discuss the framework and requirements for [PCE-ARCH] and [PCECP-REQ] discuss the framework and requirements for
PCE on both packet MPLS networks and (non-packet switch capable) PCE on both packet MPLS networks and (non-packet switch capable)
GMPLS networks. This document complements these documents by GMPLS networks. This document complements these documents by
providing some consideration of GMPLS applications in the intra- providing some considerations of GMPLS applications in the intra-
domain and inter-domain networking environments and indicating a set domain and inter-domain networking environments and indicating a set
of requirements for the extended definition of series of PCE related of requirements for the extended definition of series of PCE related
protocols. protocols.
Note that the requirements for inter-layer traffic engineering
described in [PCE-INTER LAYER-REQ] are outside of the scope of this
document.
Constraint based shortest path first (CSPF) computation within a Constraint based shortest path first (CSPF) computation within a
domain or over domains for signaling GMPLS Label Switched Paths (LSPs) domain or over domains for signaling GMPLS Label Switched Paths (LSPs)
is more stringent than that of MPLS LSPs [MPLS-AS], because the is more stringent than that of MPLS LSPs [MPLS-AS], because the
additional constraints, e.g., interface switching capability, link additional constraints, e.g., interface switching capability, link
encoding, link protection capability and so forth need to be encoding, link protection capability and so forth need to be
considered to establish GMPLS LSPs [CSPF]. GMPLS signaling protocol considered to establish GMPLS LSPs [CSPF]. GMPLS signaling protocol
[RFC3471, RFC3473] is designed taking into account bi-directionality, [RFC3471, RFC3473] is designed taking into account bi-directionality,
switching type, encoding type, SRLG, and protection attributes of the switching type, encoding type, SRLG, and protection attributes of the
TE links spanned by the path, as well as LSP encoding and switching TE links spanned by the path, as well as LSP encoding and switching
type for the end points, appropriately. type for the end points, appropriately.
skipping to change at page 3, line 23 skipping to change at page 3, line 31
2. Terminology 2. Terminology
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 [RFC2119]. document are to be interpreted as described in [RFC2119].
3. GMPLS applications of PCE 3. GMPLS applications of PCE
3.1. GMPLS network model 3.1. GMPLS network model
Figure 1 depicts a typical network, consisting of several GMPLS Figure 1 depicts a typical network, consisting of several
domains, assumed in this document. D1, D2, D3 and D4 have multiple GMPLSdomains, assumed in this document. D1, D2, D3 and D4 have
GMPLS inter-domain connections, and D5 has only one GMPLS inter- multiple GMPLS inter-domain connections, while D5 has only one GMPLS
domain connection. These domains follow the definition in [RFC4726]. inter-domain connection. These domains follow the definition in
[RFC4726].
+---------+ +---------+
+---------|GMPLS D2|----------+ +---------|GMPLS D2|----------+
| +----+----+ | | +----+----+ |
+----+----+ | +----+----+ +---------+ +----+----+ | +----+----+ +---------+
|GMPLS D1| | |GMPLS D4|---|GMPLS D5| |GMPLS D1| | |GMPLS D4|---|GMPLS D5|
+----+----+ | +----+----+ +---------+ +----+----+ | +----+----+ +---------+
| +----+----+ | | +----+----+ |
+---------|GMPLS D3|----------+ +---------|GMPLS D3|----------+
+---------+ +---------+
Figure 1: GMPLS Inter-domain network model. Figure 1: GMPLS Inter-domain network model.
Each domain is configured using various switching and link Each domain is configured using various switching and link
technologies defined in [Arch] and an end-to-end route needs to technologies defined in [Arch] and an end-to-end route needs to
respect TE link attributes like switching capability, encoding type, respect TE link attributes like switching capability, encoding type,
etc., making the problem a bit different from the case of classical etc., making the problem a bit different from the case of classical
(packet) MPLS. In order to route from one GMPLS domain to another (packet) MPLS. In order to route from one GMPLS domain to another
GMPLS domain appropriately, each domain manages traffic engineering GMPLS domain appropriately, each domain manages traffic engineering
database (TED) by PCE, and exchanges or provides route information of database (TED) by PCE, and exchanges or provides route information of
paths, while concealing its internal topology information. paths, while concealing its internal topology information.
3.2. Path computation in GMPLS network 3.2. Path computation in GMPLS network
[CSPF] describes consideration of GMPLS TE attributes during path [CSPF] describes consideration of GMPLS TE attributes during path
computation. computation. Figure 2 depicts a typical GMPLS network, consisting of
an ingress link, a transit link as well as an egress link, to
investigate a consistent guideline for GMPLS path computation. Each
link at each interface has its own switching capability, encoding
type and bandwidth.
Ingress Transit Egress Ingress Transit Egress
+-----+ link1-2 +-----+ link2-3 +-----+ link3-4 +-----+ +-----+ link1-2 +-----+ link2-3 +-----+ link3-4 +-----+
|Node1|------------>|Node2|------------>|Node3|------------>|Node4| |Node1|------------>|Node2|------------>|Node3|------------>|Node4|
| |<------------| |<------------| |<------------| | | |<------------| |<------------| |<------------| |
+-----+ link2-1 +-----+ link3-2 +-----+ link4-3 +-----+ +-----+ link2-1 +-----+ link3-2 +-----+ link4-3 +-----+
Figure 2: Path computation in GMPLS networks. Figure 2: Path computation in GMPLS networks.
For the simplicity in consideration, the below basic assumptions are For the simplicity in consideration, the below basic assumptions are
skipping to change at page 4, line 32 skipping to change at page 4, line 40
egress nodes (link1-2 and link4-3 in Figure 2) must be consistent egress nodes (link1-2 and link4-3 in Figure 2) must be consistent
with each other. with each other.
(2) Switching capabilities of all transit links including incoming (2) Switching capabilities of all transit links including incoming
links to the ingress and egress nodes (link2-1 and link3-4) should be links to the ingress and egress nodes (link2-1 and link3-4) should be
consistent with switching type of a LSP to be created. consistent with switching type of a LSP to be created.
(3) Encoding-types of all transit links should be consistent with (3) Encoding-types of all transit links should be consistent with
encoding type of a LSP to be created. encoding type of a LSP to be created.
[CSPF] indicates the possible table of switching capability, encoding [CSPF] indicates the possible tables of switching capability,
type and bandwidth at the ingress link, transiting links and the encoding type and bandwidth at the ingress link, transiting links and
egress link which need to be satisfied with the created LSP. the egress link which need to be satisfied with GMPLS path
computation of the created LSP.
The non-packet GMPLS networks (e.g., TDM networks) are usually The non-packet GMPLS networks (e.g., TDM networks) are usually
responsible for transmitting data for the client layer. These GMPLS responsible for transmitting data for the client layer. These GMPLS
networks can provide different types of connections for customer networks can provide different types of connections for customer
services based on different service bandwidth requests. services based on different service bandwidth requests.
The applications and the corresponding additional requirements for The applications and the corresponding additional requirements for
applying PCE in non-packet networks, for example, GMPLS-based TDM applying PCE in non-packet networks, for example, GMPLS-based TDM
networks, are described in Figure 3. In order to simplify the networks, are described in Figure 3. In order to simplify the
description, this document just discusses the scenario in SDH description, this document just discusses the scenario in SDH
skipping to change at page 5, line 28 skipping to change at page 5, line 35
| N5 | | | N5 | |
| | | | | |
+------+ +------+ +------+ +------+
| | | | +-----+ | | | | +-----+
| |--------------| |--------| | | |--------------| |--------| |
+------+ +------+ +-----+ +------+ +------+ +-----+
N3 N4 A2 N3 N4 A2
Figure 3: A simple SDH network Figure 3: A simple SDH network
Figure 3 shows a simple network topology, where N1, N2, N3, N4, and Figure 3 shows a simple network topology, where N1, N2, N3, N4 and N5
N5 are all SDH switches. Assume that one Ethernet service with 100M are all SDH switches. Assume that one Ethernet service with 100M
bandwidth is required from A1 to A2 over this network. The client bandwidth is required from A1 to A2 over this network. The client
Ethernet service could be provided by a VC4 connection from N1 to N4, Ethernet service could be provided by a VC4 connection from N1 to N4,
and it could also be provided by three concatenated VC3 connections and it could also be provided by three concatenated VC3 connections
(Contiguous or Virtual concatenation) from N1 to N4. (Contiguous or Virtual concatenation) from N1 to N4.
The type of connection(s) (one VC4 or three concatenated VC3) that is The type of connection(s) (one VC4 or three concatenated VC3) that is
required needs to be specified by PCC (e.g., N1 or NMS), but could required needs to be specified by PCC (e.g., N1 or NMS), but could
also be determined by PCE automatically based on policy [RFC5394]. also be determined by PCE automatically based on policy [RFC5394].
Therefore, the signal type, the type of the concatenation and the Therefore, the signal type, the type of the concatenation and the
number of the concatenation should also be considered during path number of the concatenation should also be considered during path
computation for PCE. computation for PCE.
3.3. Unnumbered Interface 3.3. Unnumbered Interfaces
GMPLS support unnumbered interface ID that is defined in [RFC 3477], GMPLS support unnumbered interface ID that is defined in [RFC 3477],
which means that the endpoints of the path may be unnumbered. It which means that the endpoints of the path may be unnumbered. It
should also be possible to request a Path between a numbered link and should also be possible to request a path between a numbered link and
an unnumbered link, or a P2MP path between different types of an unnumbered link, or a P2MP path between different types of
endpoints. Therefore, the PCC should be capable of indicating the endpoints. Therefore, the PCC should be capable of indicating the
unnumbered interface ID of the endpoints in the PCReq message. unnumbered interface ID of the endpoints in the PCReq message.
3.4. Asymmetric Bandwidth Path Computation 3.4. Asymmetric Bandwidth Path Computation
As per [RFC 5467], GMPLS signaling can be used for setting up an As per [RFC 5467], GMPLS signaling can be used for setting up an
asymmetric bandwidth bidirectional LSP. If a PCE is responsible for asymmetric bandwidth bidirectional LSP. If a PCE is responsible for
the path computation, the PCE should be capable of computing a path the path computation, the PCE should be capable of computing a path
for the bidirectional LSP with asymmetric bandwidth. It means that for the bidirectional LSP with asymmetric bandwidth. It means that
skipping to change at page 6, line 26 skipping to change at page 6, line 35
In this section, we describe requirements for GMPLS applications of In this section, we describe requirements for GMPLS applications of
PCE in order to establish GMPLS LSP. PCE in order to establish GMPLS LSP.
4.1. Requirements of Path Computation Request 4.1. Requirements of Path Computation Request
As for path computation in GMPLS networks as discussed in section 3, As for path computation in GMPLS networks as discussed in section 3,
the PCE needs to consider the GMPLS TE attributes appropriately the PCE needs to consider the GMPLS TE attributes appropriately
according to tables in [CSPF] once a PCC or another PCE requests a according to tables in [CSPF] once a PCC or another PCE requests a
path computation. Indeed, the path calculation request message from path computation. Indeed, the path calculation request message from
the PCC or the PCE needs to contain the information specifying the PCC or the PCE needs to contain the information specifying
appropriate attributes. Additional attributes to those already appropriate attributes. According to [RFC5440],[PCEP-EXT],[ PCE-WSON-
defined in [PCECP] are as follows. REQ] and to RSVP procedures like explicit label control(ELC),the
additional attributes introduced are as follows: [RFC5440]
(1) Switching capability: PSC1-4, L2SC, DCSC [DCSC-Ext], 802_1 PBB-TE (1) Switching capability: PSC1-4, L2SC, DCSC [DCSC-Ext], 802_1 PBB-TE
[GMPLS-PBB-TE], TDM, LSC, FSC [GMPLS-PBB-TE], TDM, LSC, FSC
(2) Encoding type: as defined in [RFC4202], [RFC4203], e.g., Ethernet, (2) Encoding type: as defined in [RFC4202], [RFC4203], e.g., Ethernet,
SONET/SDH, Lambda, etc. SONET/SDH, Lambda, etc.
(3) Signal Type: Indicates the type of elementary signal that (3) Signal Type: Indicates the type of elementary signal that
constitutes the requested LSP. A lot of signal types with constitutes the requested LSP. A lot of signal types with
different granularity have been defined in SONET/SDH and G.709 ODUk, 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 such as VC11, VC12, VC2, VC3 and VC4 in SDH, and ODU1, ODU2 and ODU3
in G.709 ODUk. See [RFC4606] and [RFC4328]. in G.709 ODUk. See[RFC4606] , [RFC4328]and [OSPF-G709] or [RSVP-TE-
G709].
(4) Concatenation Type: In SDH/SONET and G.709 ODUk networks, two (4) Concatenation Type: In SDH/SONET and G.709 ODUk networks, two
kinds of concatenation modes are defined: contiguous kinds of concatenation modes are defined: contiguous
concatenation which requires co-route for each member signal and concatenation which requires co-route for each member signal and
requires all the interfaces along the path to support this capability, requires all the interfaces along the path to support this capability,
and virtual concatenation which allows diverse routes for the member and virtual concatenation which allows diverse routes for the member
signals and only requires the ingress and egress interfaces to signals and only requires the ingress and egress interfaces to
support this capability. Note that for the virtual concatenation, it support this capability. Note that for the virtual concatenation, it
also may specify co-routed or separated-routed. See [RFC4606] and also may specify co-routed or separated-routed. See [RFC4606] and
[RFC4328] about Concatenation information. [RFC4328] about concatenation information.
(5) Concatenation Number: Indicates the number of signals that are (5) Concatenation Number: Indicates the number of signals that are
requested to be contiguously or virtually concatenated. Also see requested to be contiguously or virtually concatenated. Also see
[RFC4606] and [RFC4328]. [RFC4606] and [RFC4328].
(6) Wavelength Label: as defined in [Lambda-label]. (6) Technology specific label(s) such as wavelength label as defined
in [RFC6205].
(7) e2e Path protection type: as defined in [RFC4872], e.g., 1+1 (7) e2e Path protection type: as defined in [RFC4872], e.g., 1+1
protection, 1:1 protection, (pre-planned) rerouting, etc. protection, 1:1 protection, (pre-planned) rerouting, etc.
(8) Administrative group: as defined in [RFC3630]. (8) Administrative group: as defined in [RFC3630].
(9) Link Protection type: as defined in [RFC4203]. (9) Link Protection type: as defined in [RFC4203].
(10)Support for unnumbered interfaces: as defined in [RFC3477]. (10)Support for unnumbered interfaces: as defined in [RFC3477].
(11)Support for asymmetric bandwidth request: as defined in [RFC (11)Support for asymmetric bandwidth request: as defined in [RFC
5467]. 5467].
(12)Support for explicit label control during the path computation.
4.2. Requirements of Path Computation Reply 4.2. Requirements of Path Computation Reply
As described above, a PCC needs to support to initiate a PCReq As described above, a PCC needs to support to initiate a PCReq
message specifying above mentioned attributes. The PCE needs to message specifying above mentioned attributes. The PCE needs to
compute the path that satisfies the constraints which are specified compute the path that satisfies the constraints which are specified
in the PCReq message. Then the PCE needs to send a PCRep message in the PCReq message. Then the PCE needs to send a PCRep message
including the computation result to the PCC. For Path Computation including the computation result to the PCC. For Path Computation
Reply message (PCRep) in GMPLS networks, there are some additional Reply message (PCRep) in GMPLS networks, there are some additional
requirements. The PCEP PCRep message needs to be extended to meet the requirements. The PCEP PCRep message needs to be extended to meet the
following requirements. following requirements.
skipping to change at page 8, line 46 skipping to change at page 9, line 16
This document has no actions for IANA. This document has no actions for IANA.
7. Acknowledgement 7. Acknowledgement
The author would like to express the thanks to Shuichi Okamoto for The author would like to express the thanks to Shuichi Okamoto for
his comments. his comments.
8. References 8. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[PCE-ARCH] A. Farrel, et al, "A Path Computation Element (PCE)-Based [PCE-ARCH] A. Farrel, et al, "A Path Computation Element (PCE)-Based
Architecture", RFC4655, Aug., 2006. Architecture", RFC4655, Aug., 2006.
[PCECP-REQ] J. Ash, et al, "Path computation element (PCE) communication [PCECP-REQ] J. Ash, et al, "Path computation element (PCE)
protocol generic requirements", RFC4657, Sept., 2007. communication protocol generic requirements", RFC4657,
Sept., 2007.
[MPLS-AS] R. Zhan, et al, "MPLS Inter-Autonomous System (AS) Traffic [PCE-INTER LAYER-REQ] T.Takeda,et al,"PCC-PCE Communication and PCE
Engineering (TE) Requirements", RFC4216, November 2005. Discovery Requirements for Inter-Layer
Engineering",December 2010.
[CSPF] T. Otani, et al, "Considering Generalized Multiprotocol [MPLS-AS] R. Zhan, et al, "MPLS Inter-Autonomous System (AS)
Label Switching Traffic Engineering Attributes During Path Traffic Engineering (TE) Requirements", RFC4216, November
Computation", draft-otani-ccamp-gmpls-cspf-constraints- 2005.
07.txt, Feb., 2008.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching [CSPF] T. Otani, et al, "Considering Generalized Multiprotocol
(MPLS) Signaling Functional Description", RFC 3471, January Label Switching Traffic Engineering Attributes During
2003. Path Computation", draft-otani-ccamp-gmpls-cspf-
constraints-07.txt, Feb., 2008.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(MPLS) Signaling - Resource ReserVation Protocol Traffic (MPLS) Signaling Functional Description", RFC 3471,
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. January 2003.
[RFC4726] A. Farrel, et al, "A framework for inter-domain MPLS traffic [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
engineering", RFC4726, November 2006. (MPLS) Signaling - Resource ReserVation Protocol Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[Arch] E. Mannie, et al, "Generalized Multi-Protocol Label [RFC4726] A. Farrel, et al, "A framework for inter-domain MPLS
Switching Architecture", RFC3945, October, 2004. traffic engineering", RFC4726, November 2006.
[PCECP] J.P. Vasseur, et al, "Path Computation Element (PCE) [Arch] E. Mannie, et al, "Generalized Multi-Protocol Label
Communication Protocol (PCEP)", RFC5440, March 2009. Switching Architecture", RFC3945, October, 2004.
[RFC4202] K. Kompella, and Y. Rekhter, "Routing Extensions in Support [RFC5394] I.Bryskin,et al,"Policy-Enabled Path Computation
of Generalized Multi-Protocol Label Switching", RFC4202, Framework",RFC5394,December 2008.
Oct. 2005.
[RFC4203] K. Kompella, and Y. Rekhter, "OSPF Extensions in Support of [RFC3477] K.Kompella,et al,"Signalling Unnumbered Links in Resource
Generalized Multi-Protocol Label Switching", RFC4203, Oct. ReSerVation Protocol-Traffic Engineering(RSVP-
2005. TE)",January 2003.
[RFC4872] J.P. Lang, Ed., "RSVP-TE Extensions in Support of End-to-End [RFC5476] B.Claise,Ed,"Packet Sampling(PSAMP) Protocol
Generalized Multi-Protocol Label Switching (GMPLS) Specifications",March 2009.
Recovery", RFC4872, May 2007.
[GMPLS-TEMIB] T. Nadeau and A. Farrel, Ed., "Generalized [RFC5440] J.P. Vasseur, et al, "Path Computation Element (PCE)
Multiprotocol Label Switching (GMPLS) Traffic Engineering Communication Protocol (PCEP)", RFC5440, March 2009.
Management Information Base", RFC4802, Feb. 2007.
[RFC3630] D. Katz et al., "Traffic Engineering (TE) Extensions to OSPF [PCEP-EXT] C.Margaria,et al, "PCEP extensions for GMPLS",draft-
Version 2", RFC3630, September 2003. ietf-pce-gmpls-PCEP-EXTs-02.txt,March 2011.
[Lambda-label] T. Otani, Ed., "Generalized Labels for G.694 Lambda- [PCE-WSON-REQ] Y.Lee, et al,"PCEP Requirements for WSON Routing and
Switching Capable Label Switching Routers", draft-ietf- Wavelength Assignment",draft-ietf-pce-wson-routing-
ccamp-gmpls-g-694-lambda-labels, in progress. wavelength-04.txt,March 2011.
[RFC5394] I. Bryskin et al., " Policy-Enabled Path Computation [RFC4202] K. Kompella, and Y. Rekhter, "Routing Extensions in
Framework", RFC5394, December 2008. Support of Generalized Multi-Protocol Label Switching",
RFC4202, Oct. 2005.
[RFC4606] E. Mannie and D. Papadimitriou, "Generalized Multi-Protocol [RFC4203] K. Kompella, and Y. Rekhter, "OSPF Extensions in Support
Label Switching (GMPLS) Extensions for Synchronous Optical of Generalized Multi-Protocol Label Switching", RFC4203,
Network (SONET) and Synchronous Digital Hierarchy (SDH) Oct. 2005.
Control", RFC4606, August 2006.
[RFC4328] D. Papadimitriou, Ed., "Generalized Multi-Protocol Label [RFC4872] J.P. Lang, Ed., "RSVP-TE Extensions in Support of End-to-
Switching (GMPLS) Signaling Extensions for G.709 Optical End Generalized Multi-Protocol Label Switching (GMPLS)
Transport Networks Control", RFC4328, January 2006. Recovery", RFC4872, May 2007.
[DCSC-Ext] Lou Berger, et al.,"Generalized MPLS (GMPLS) Data Channel [GMPLS-TEMIB] T. Nadeau and A. Farrel, Ed., "Generalized
Switching Capable (DCSC) and Channel Set Label Extensions", Multiprotocol Label Switching (GMPLS) Traffic Engineering
in progress. Management Information Base", RFC4802, Feb. 2007.
[GMPLS-PBB-TE] Don Fedyk, et al., "Generalized Multiprotocol Label [RFC3630] D. Katz et al., "Traffic Engineering (TE) Extensions to
Switching (GMPLS) control of Ethernet PBB-TE", in progress. OSPF Version 2", RFC3630, September 2003.
[Lambda-label] T. Otani, Ed., "Generalized Labels for G.694 Lambda-
Switching Capable Label Switching Routers", draft-ietf-
ccamp-gmpls-g-694-lambda-labels, in progress.
[RFC5394] I. Bryskin et al., " Policy-Enabled Path Computation
Framework", RFC5394, December 2008.
[RFC4606] E. Mannie and D. Papadimitriou, "Generalized Multi-
Protocol Label Switching (GMPLS) Extensions for
Synchronous Optical Network (SONET) and Synchronous
Digital Hierarchy (SDH) Control", RFC4606, August 2006.
[RFC4328] D. Papadimitriou, Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Extensions for G.709 Optical
Transport Networks Control", RFC4328, January 2006.
[RFC3477] K.Kompella,"Signalling Unnumbered Links in Resource
ReServation Protocol-Traffic Engineering(RSVP-
TE)",January 2003.
[OSPF-G709] D.Ceccarelli,et al,"Traffic Engineering Extensions to
OSPF for Generalized MPLS(GMPLS) Control of Evolving
G.709 OTN Networks",March 2011.
[RSVP-TE-G709] Fatai Zhang,et al,"Generalized Multi-Protocol Label
Switching(GMPLS) Signaling Extensions for the evolving
G.709 Optical Transport Network Control",March 2011.
[DCSC-Ext] Lou Berger, et al.,"Generalized MPLS (GMPLS) Data Channel
Switching Capable (DCSC) and Channel Set Label
Extensions", in progress.
[GMPLS-PBB-TE] Don Fedyk, et al., "Generalized Multiprotocol Label
Switching (GMPLS) control of Ethernet PBB-TE", in
progress.
9. Authors' Addresses 9. Authors' Addresses
Tomohiro Otani Tomohiro Otani
KDDI Corporation KDDI Corporation
2-3-2 Nishi-shinjuku Shinjuku-ku, Tokyo 163-8003 Japan 2-3-2 Nishi-shinjuku Shinjuku-ku, Tokyo 163-8003 Japan
Phone: +81-3-3347-6006 Phone: +81-3-3347-6006
Email: tm-otani@kddi.com Email: tm-otani@kddi.com
Kenichi Ogaki Kenichi Ogaki
 End of changes. 39 change blocks. 
101 lines changed or deleted 153 lines changed or added

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