draft-ietf-ccamp-gmpls-ospf-g709v3-08.txt   draft-ietf-ccamp-gmpls-ospf-g709v3-09.txt 
CCAMP Working Group D. Ceccarelli, Ed. CCAMP Working Group D. Ceccarelli, Ed.
Internet-Draft D. Caviglia Internet-Draft Ericsson
Updates: 4203 (if approved) Ericsson
Intended status: Standards Track F. Zhang Intended status: Standards Track F. Zhang
Expires: January 5, 2014 D. Li Expires: April 4, 2014 Huawei Technologies
Huawei Technologies
S. Belotti S. Belotti
P. Grandi
Alcatel-Lucent Alcatel-Lucent
R. Rao R. Rao
K. Pithewan
Infinera Corporation Infinera Corporation
J. Drake J. Drake
Juniper Juniper
July 4, 2013 October 1, 2013
Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS)
Control of Evolving G.709 OTN Networks Control of Evolving G.709 OTN Networks
draft-ietf-ccamp-gmpls-ospf-g709v3-08 draft-ietf-ccamp-gmpls-ospf-g709v3-09
Abstract Abstract
This document describes Open Shortest Path First - Traffic This document describes Open Shortest Path First - Traffic
Engineering (OSPF-TE) routing protocol extensions to support Engineering (OSPF-TE) routing protocol extensions to support
Generalized MPLS (GMPLS) control of Optical Transport Networks (OTN) Generalized MPLS (GMPLS) control of Optical Transport Networks (OTN)
specified in ITU-T Recommendation G.709 as published in 2012. It specified in ITU-T Recommendation G.709 as published in 2012. It
extends mechanisms defined in RFC4203. extends mechanisms defined in RFC4203.
Status of this Memo Status of this Memo
skipping to change at page 1, line 46 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on January 5, 2014. This Internet-Draft will expire on April 4, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
skipping to change at page 2, line 26 skipping to change at page 2, line 22
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. OSPF-TE Extensions . . . . . . . . . . . . . . . . . . . . . . 3 2. OSPF-TE Extensions . . . . . . . . . . . . . . . . . . . . . . 3
3. TE-Link Representation . . . . . . . . . . . . . . . . . . . . 5 3. TE-Link Representation . . . . . . . . . . . . . . . . . . . . 5
4. ISCD format extensions . . . . . . . . . . . . . . . . . . . . 5 4. ISCD format extensions . . . . . . . . . . . . . . . . . . . . 5
4.1. Switching Capability Specific Information . . . . . . . . 7 4.1. Switching Capability Specific Information . . . . . . . . 7
4.1.1. Switching Capability Specific Information for 4.1.1. Switching Capability Specific Information for
fixed containers . . . . . . . . . . . . . . . . . . . 7 fixed containers . . . . . . . . . . . . . . . . . . . 8
4.1.2. Switching Capability Specific Information for 4.1.2. Switching Capability Specific Information for
variable containers . . . . . . . . . . . . . . . . . 8 variable containers . . . . . . . . . . . . . . . . . 8
4.1.3. Switching Capability Specific Information - Field 4.1.3. Switching Capability Specific Information - Field
values and explanation . . . . . . . . . . . . . . . . 9 values and explanation . . . . . . . . . . . . . . . . 9
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. MAX LSP Bandwidth fields in the ISCD . . . . . . . . . . . 12 5.1. MAX LSP Bandwidth fields in the ISCD . . . . . . . . . . . 12
5.2. Example of T,S and TS granularity utilization . . . . . . 14 5.2. Example of T,S and TS granularity utilization . . . . . . 14
5.2.1. Example of different TS Granularities . . . . . . . . 15 5.2.1. Example of different TS Granularities . . . . . . . . 15
5.3. Example of ODUflex advertisement . . . . . . . . . . . . . 17 5.3. Example of ODUflex advertisement . . . . . . . . . . . . . 17
5.4. Example of single stage muxing . . . . . . . . . . . . . . 20 5.4. Example of single stage muxing . . . . . . . . . . . . . . 20
5.5. Example of multi stage muxing - Unbundled link . . . . . . 22 5.5. Example of multi stage muxing - Unbundled link . . . . . . 22
5.6. Example of multi stage muxing - Bundled links . . . . . . 24 5.6. Example of multi stage muxing - Bundled links . . . . . . 24
5.7. Example of component links with non homogeneous 5.7. Example of component links with non homogeneous
hierarchies . . . . . . . . . . . . . . . . . . . . . . . 25 hierarchies . . . . . . . . . . . . . . . . . . . . . . . 25
6. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 27 6. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
8.1. Switching types . . . . . . . . . . . . . . . . . . . . . 28
8.2. New TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 28
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
11.1. Normative References . . . . . . . . . . . . . . . . . . . 31 11.1. Normative References . . . . . . . . . . . . . . . . . . . 32
11.2. Informative References . . . . . . . . . . . . . . . . . . 31 11.2. Informative References . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
G.709 Optical Transport Network (OTN) [G.709-2012] includes new fixed G.709 Optical Transport Network (OTN) [G.709-2012] includes new fixed
and flexible ODU (Optical channel Data Unit) containers, two types of and flexible ODU (Optical channel Data Unit) containers, two types of
Tributary Slots (i.e. 1.25Gbps and 2.5Gbps), and supports various Tributary Slots (i.e. 1.25Gbps and 2.5Gbps), and supports various
multiplexing relationships (e.g., ODUj multiplexed into ODUk (j<k)), multiplexing relationships (e.g., ODUj multiplexed into ODUk (j<k)),
two different tributary slots for ODUk (K=1, 2, 3) and ODUflex two different tributary slots for ODUk (K=1, 2, 3) and ODUflex
service type. In order to present this information in routing, this service type. In order to present this information in routing, this
document provides OTN technology specific encoding for use in GMPLS document provides OTN technology specific encoding for use in GMPLS
skipping to change at page 3, line 51 skipping to change at page 3, line 51
and (2) the TE link TLV. One or more sub-TLVs can be nested into the and (2) the TE link TLV. One or more sub-TLVs can be nested into the
two top-level TLVs. The sub-TLV set for the two top-level TLVs are two top-level TLVs. The sub-TLV set for the two top-level TLVs are
also defined in [RFC3630] and [RFC4203]. also defined in [RFC3630] and [RFC4203].
As discussed in [OTN-FWK] and [OTN-INFO], OSPF-TE must be extended so As discussed in [OTN-FWK] and [OTN-INFO], OSPF-TE must be extended so
to be able to advertise the termination and switching capabilities to be able to advertise the termination and switching capabilities
related to each different ODUj and ODUk/OTUk (Optical Transport Unit) related to each different ODUj and ODUk/OTUk (Optical Transport Unit)
and the advertisement of related multiplexing capabilities. These and the advertisement of related multiplexing capabilities. These
capabilities are carried in the Interface Switching Capability capabilities are carried in the Interface Switching Capability
Descriptor (ISCD) Switching Capability-specific information field Descriptor (ISCD) Switching Capability-specific information field
using formats defined in this document. As discussed in [swcaps- using formats defined in this document. As discussed in [SWCAP-
update], the use of a technology specific Switching Capability- UPDT], the use of a technology specific Switching Capability-specific
specific information field necessitates the definition of a new information field necessitates the definition of a new Switching
Switching Capability value and associated new Switching Capability. Capability value and associated new Switching Capability.
In the following we will use ODUj to indicate a service type that is In the following we will use ODUj to indicate a service type that is
multiplexed into a higher order ODU, ODUk to indicate a higher order multiplexed into a higher order ODU, ODUk to indicate a higher order
ODU including an ODUj and ODUk/OTUk to indicate the layer mapped into ODU including an ODUj and ODUk/OTUk to indicate the layer mapped into
the OTUk. Moreover ODUj(S) and ODUk(S) are used to indicate ODUj and the OTUk. Moreover ODUj(S) and ODUk(S) are used to indicate ODUj and
ODUk supporting switching capability only, and the ODUj->ODUk format ODUk supporting switching capability only, and the ODUj->ODUk format
is used to indicate the ODUj into ODUk multiplexing capability. is used to indicate the ODUj into ODUk multiplexing capability.
This notation can be repeated as needed depending on the number of This notation can be repeated as needed depending on the number of
multiplexing levels. In the following the term "multiplexing tree" multiplexing levels. In the following the term "multiplexing tree"
skipping to change at page 6, line 11 skipping to change at page 6, line 11
Capability value for OTN [G.709-2012] as follows: Capability value for OTN [G.709-2012] as follows:
Value Type Value Type
----- ---- ----- ----
110 (TBA by IANA) OTN-TDM capable (OTN-TDM) 110 (TBA by IANA) OTN-TDM capable (OTN-TDM)
When supporting the extensions defined in this document, the When supporting the extensions defined in this document, the
Switching Capability and Encoding values MUST be used as follows: Switching Capability and Encoding values MUST be used as follows:
- Switching Capability = OTN-TDM - Switching Capability = OTN-TDM
- Encoding Type = G.709 ODUk (Digital Path) [as defined in RFC4328] - Encoding Type = G.709 ODUk (Digital Path) as defined in [RFC4328]
Both for fixed and flexible ODUs the same switching type and encoding Both for fixed and flexible ODUs the same switching type and encoding
values MUST be used. When Switching Capability and Encoding fields values MUST be used. When Switching Capability and Encoding fields
are set to values as stated above, the Interface Switching Capability are set to values as stated above, the Interface Switching Capability
Descriptor MUST be interpreted as defined in [RFC4203]. Descriptor MUST be interpreted as defined in [RFC4203].
Maximum LSP Bandwidth Maximum LSP Bandwidth
The MAX LSP Bandwidth field is used according to [RFC4203]: i.e. 0 <= The MAX LSP Bandwidth field is used according to [RFC4203]: i.e. 0 <=
MAX LSP Bandwidth <= ODUk/OTUk and intermediate values are those on MAX LSP Bandwidth <= ODUk/OTUk and intermediate values are those on
the branch of OTN switching hierarchy supported by the interface. the branch of OTN switching hierarchy supported by the interface.
E.g. in the OTU4 link it could be possible to have ODU4 as MAX LSP E.g. in the OTU4 link it could be possible to have ODU4 as MAX LSP
Bandwidth for some priorities, ODU3 for others, ODU2 for some others Bandwidth for some priorities, ODU3 for others, ODU2 for some others
etc. The bandwidth unit is in bytes per second and the encoding MUST etc. The bandwidth unit is in bytes per second and the encoding MUST
be in Institute of Electrical and Electronic Engineers (IEEE) be in Institute of Electrical and Electronic Engineers (IEEE)
floating point format. The discrete values for various ODUs is shown floating point format. The discrete values for various ODUs is shown
in the table below. in the table below (please note that there are 1000 bits in a kbit
according to normal practices in telecommunications).
+---------------------+------------------------------+-----------------+ +---------------------+------------------------------+-----------------+
| ODU Type | ODU nominal bit rate |Value in Byte/Sec| | ODU Type | ODU nominal bit rate |Value in Byte/Sec|
| | |(floating p. val)|
+---------------------+------------------------------+-----------------+ +---------------------+------------------------------+-----------------+
| ODU0 | 1 244 160 kbits/s | 0x4D1450C0 | | ODU0 | 1 244 160 kbit/s | 0x4D1450C0 |
| ODU1 | 239/238 x 2 488 320 kbit/s | 0x4D94F048 | | ODU1 | 239/238 x 2 488 320 kbit/s | 0x4D94F048 |
| ODU2 | 239/237 x 9 953 280 kbit/s | 0x4E959129 | | ODU2 | 239/237 x 9 953 280 kbit/s | 0x4E959129 |
| ODU3 | 239/236 x 39 813 120 kbit/s | 0X4F963367 | | ODU3 | 239/236 x 39 813 120 kbit/s | 0x4F963367 |
| ODU4 | 239/227 x 99 532 800 kbit/s | 0x504331E3 | | ODU4 | 239/227 x 99 532 800 kbit/s | 0x504331E3 |
| ODU2e | 239/237 x 10 312 500 kbit/s | 0x4E9AF70A | | ODU2e | 239/237 x 10 312 500 kbit/s | 0x4E9AF70A |
| | | | | | | |
| ODUflex for CBR | | MAX LSP | | ODUflex for CBR | | MAX LSP |
| Client signals | 239/238 x client signal | BANDWIDTH | | Client signals | 239/238 x client signal | BANDWIDTH |
| | bit rate | | | | bit rate | |
| ODUflex for GFP-F | | MAX LSP | | ODUflex for GFP-F | | MAX LSP |
|Mapped client signal | Configured bit rate | BANDWIDTH | |Mapped client signal | Configured bit rate | BANDWIDTH |
| | | | | | | |
| | | | | | | |
skipping to change at page 11, line 32 skipping to change at page 11, line 32
- Unreserved Padding (16 bits): The Padding field is used to - Unreserved Padding (16 bits): The Padding field is used to
ensure the 32 bit alignment of Unreserved ODUj fields. When ensure the 32 bit alignment of Unreserved ODUj fields. When
present the Unreserved Padding field is 16 bits (2 byte) long. present the Unreserved Padding field is 16 bits (2 byte) long.
When the number of priorities is odd, the Unreserved Padding field When the number of priorities is odd, the Unreserved Padding field
MUST be included. When the number of priorities is even, the MUST be included. When the number of priorities is even, the
Unreserved Padding MUST be omitted. Unreserved Padding MUST be omitted.
- Unreserved Bandwidth (32 bits): This field indicates the - Unreserved Bandwidth (32 bits): This field indicates the
Unreserved Bandwidth at a particular priority level. This field Unreserved Bandwidth at a particular priority level. This field
MUST be set to the bandwidth, in bits/s in IEEE floating point MUST be set to the bandwidth, in Bytes/sec in IEEE floating point
format, available at the indicated Signal Type for a particular format, available at the indicated Signal Type for a particular
priority level. One field MUST be present for each bit set in the priority level. One field MUST be present for each bit set in the
Priority field, and is ordered to match the Priority field. Priority field, and is ordered to match the Priority field.
Fields MUST NOT be present for priority levels that are not Fields MUST NOT be present for priority levels that are not
indicated in the Priority field. indicated in the Priority field.
- Maximum LSP Bandwidth (32 bit): This field indicates the maximum - Maximum LSP Bandwidth (32 bit): This field indicates the maximum
bandwidth that can be allocated for a single LSP at a particular bandwidth that can be allocated for a single LSP at a particular
priority level. This field MUST be set to the maximum bandwidth, priority level. This field MUST be set to the maximum bandwidth,
in bits/s in IEEE floating point format, available to a single LSP in Bytes/sec in IEEE floating point format, available to a single
at the indicated Signal Type for a particular priority level. One LSP at the indicated Signal Type for a particular priority level.
field MUST be present for each bit set in the Priority field, and One field MUST be present for each bit set in the Priority field,
is ordered to match the Priority field. Fields MUST NOT be and is ordered to match the Priority field. Fields MUST NOT be
present for priority levels that are not indicated in the Priority present for priority levels that are not indicated in the Priority
field. The advertisement of the MAX LSP Bandwidth MUST take into field. The advertisement of the MAX LSP Bandwidth MUST take into
account HO OPUk bit rate tolerance and be calculated according to account HO OPUk bit rate tolerance and be calculated according to
the following formula: the following formula:
Max LSP BW = (# available TSs) * (ODTUk.ts nominal bit rate) * Max LSP BW = (# available TSs) * (ODTUk.ts nominal bit rate) *
(1-HO OPUk bit rate tolerance) (1-HO OPUk bit rate tolerance)
5. Examples 5. Examples
skipping to change at page 28, line 28 skipping to change at page 28, line 28
the transmission of this information, and those or other mechanisms the transmission of this information, and those or other mechanisms
should be used to secure and/or authenticate the information carried should be used to secure and/or authenticate the information carried
in the Opaque LSAs. in the Opaque LSAs.
For security threats, defensive techniques, monitoring/detection/ For security threats, defensive techniques, monitoring/detection/
reporting of security attacks and requirements please refer to reporting of security attacks and requirements please refer to
[RFC5920] . [RFC5920] .
8. IANA Considerations 8. IANA Considerations
8.1. Switching types
Upon approval of this document, IANA will make the assignment in the Upon approval of this document, IANA will make the assignment in the
"Switching Types" section of the "GMPLS Signaling Parameters" "Switching Types" section of the "GMPLS Signaling Parameters"
registry located at registry located at
http://www.iana.org/assignments/gmpls-sig-parameters: http://www.iana.org/assignments/gmpls-sig-parameters:
Value Name Reference Value Name Reference
--------- -------------------------- ---------- --------- -------------------------- ----------
110 (*) OTN-TDM capable (OTN-TDM) [This.I-D] 110 (*) OTN-TDM capable (OTN-TDM) [This.I-D]
(*) Suggested value (*) Suggested value
Same type of modification needs to applied to the IANA-GMPLS-TC-MIB
at https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib
8.2. New TLVs
This document defines 2 new TLVs that are carried in Interface This document defines 2 new TLVs that are carried in Interface
Switching Capability Descriptors [RFC4203] with Signal Type OTN-TDM. Switching Capability Descriptors [RFC4203] with Signal Type OTN-TDM.
Each TLV includes a 16-bit type identifier (the T-field). The same Each TLV includes a 16-bit type identifier (the T-field). The same
T-field values are applicable to the new sub-TLV. T-field values are applicable to the new sub-TLV.
Upon approval of this document, IANA will create and maintain a new Upon approval of this document, IANA will create and maintain a new
registry, the "Types for sub-TLVs of OTN-TDM SCSI (Switch Capability registry, the "Types for sub-TLVs of OTN-TDM SCSI (Switch Capability
Specific Information)" registry under the "Open Shortest Path First Specific Information)" registry under the "Open Shortest Path First
(OSPF) Traffic Engineering TLVs" registry, see http://www.iana.org/ (OSPF) Traffic Engineering TLVs" registry, see http://www.iana.org/
assignments/ospf-traffic-eng-tlvs/ospf-traffic-eng-tlvs.xml, with the assignments/ospf-traffic-eng-tlvs/ospf-traffic-eng-tlvs.xml, with the
TLV types as follows: TLV types as follows:
skipping to change at page 29, line 16 skipping to change at page 29, line 24
This document defines new TLV types as follows: This document defines new TLV types as follows:
Value Sub-TLV Reference Value Sub-TLV Reference
--------- -------------------------- ---------- --------- -------------------------- ----------
0 Reserved [This.I-D] 0 Reserved [This.I-D]
1 Unreserved Bandwidth for [This.I-D] 1 Unreserved Bandwidth for [This.I-D]
fixed containers fixed containers
2 Unreserved/MAX Bandwidth for [This.I-D] 2 Unreserved/MAX Bandwidth for [This.I-D]
flexible containers flexible containers
3-65535 Unassigned
Types are to be assigned via Standards Action as defined in Types are to be assigned via Standards Action as defined in
[RFC5226]. [RFC5226].
9. Contributors 9. Contributors
Diego Caviglia, Ericsson
Via E.Melen, 77 - Genova - Italy
Email: diego.caviglia@ericsson.com
Dan Li, Huawei Technologies
Bantian, Longgang District - Shenzhen 518129 P.R.China
Email: danli@huawei.com
Pietro Vittorio Grandi, Alcatel-Lucent
Via Trento, 30 - Vimercate - Italy
Email: pietro_vittorio.grandi@alcatel-lucent.com
Khuzema Pithewan, Infinera Corporation
140 Caspian CT., Sunnyvale - CA - USA
Email: kpithewan@infinera.com
Xiaobing Zi, Huawei Technologies Xiaobing Zi, Huawei Technologies
Email: zixiaobing@huawei.com Email: zixiaobing@huawei.com
Francesco Fondelli, Ericsson Francesco Fondelli, Ericsson
Email: francesco.fondelli@ericsson.com Email: francesco.fondelli@ericsson.com
Marco Corsi Marco Corsi
skipping to change at page 31, line 11 skipping to change at page 32, line 4
Malcolm Betts Malcolm Betts
Malcolm.betts@zte.com.cn Malcolm.betts@zte.com.cn
10. Acknowledgements 10. Acknowledgements
The authors would like to thank Fred Gruman and Lou Berger for the The authors would like to thank Fred Gruman and Lou Berger for the
precious comments and suggestions. precious comments and suggestions.
11. References 11. References
11.1. Normative References 11.1. Normative References
[G.709-2012]
ITU-T, "Draft revised G.709, version 4", consented
by ITU-T in 2012.
[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.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, (TE) Extensions to OSPF Version 2", RFC 3630,
September 2003. September 2003.
[RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support
of Generalized Multi-Protocol Label Switching (GMPLS)", of Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4203, October 2005. RFC 4203, October 2005.
skipping to change at page 32, line 24 skipping to change at page 33, line 11
[RFC6163] Lee, Y., Bernstein, G., and W. Imajuku, "Framework for [RFC6163] Lee, Y., Bernstein, G., and W. Imajuku, "Framework for
GMPLS and Path Computation Element (PCE) Control of GMPLS and Path Computation Element (PCE) Control of
Wavelength Switched Optical Networks (WSONs)", RFC 6163, Wavelength Switched Optical Networks (WSONs)", RFC 6163,
April 2011. April 2011.
[RFC6566] Lee, Y., Bernstein, G., Li, D., and G. Martinelli, "A [RFC6566] Lee, Y., Bernstein, G., Li, D., and G. Martinelli, "A
Framework for the Control of Wavelength Switched Optical Framework for the Control of Wavelength Switched Optical
Networks (WSONs) with Impairments", RFC 6566, March 2012. Networks (WSONs) with Impairments", RFC 6566, March 2012.
[SWCAP-UPDT]
F.Zhang, D.Li, H.Li, S.Belotti, D.Ceccarelli, "Framework
for GMPLS and PCE Control of G.709 Optical Transport
networks, work in progress
draft-ietf-ccamp-gmpls-g709-framework-13", June 2013.
Authors' Addresses Authors' Addresses
Daniele Ceccarelli (editor) Daniele Ceccarelli (editor)
Ericsson Ericsson
Via E.Melen 77 Via E.Melen 77
Genova - Erzelli Genova - Erzelli
Italy Italy
Email: daniele.ceccarelli@ericsson.com Email: daniele.ceccarelli@ericsson.com
Diego Caviglia
Ericsson
Via E.Melen 77
Genova - Erzelli
Italy
Email: diego.caviglia@ericsson.com
Fatai Zhang Fatai Zhang
Huawei Technologies Huawei Technologies
F3-5-B R&D Center, Huawei Base F3-5-B R&D Center, Huawei Base
Shenzhen 518129 P.R.China Bantian, Longgang District Shenzhen 518129 P.R.China Bantian, Longgang District
Phone: +86-755-28972912 Phone: +86-755-28972912
Email: zhangfatai@huawei.com Email: zhangfatai@huawei.com
Dan Li
Huawei Technologies
F3-5-B R&D Center, Huawei Base
Shenzhen 518129 P.R.China Bantian, Longgang District
Phone: +86-755-28973237
Email: danli@huawei.com
Sergio Belotti Sergio Belotti
Alcatel-Lucent Alcatel-Lucent
Via Trento, 30 Via Trento, 30
Vimercate Vimercate
Italy Italy
Email: sergio.belotti@alcatel-lucent.com Email: sergio.belotti@alcatel-lucent.com
Pietro Vittorio Grandi
Alcatel-Lucent
Via Trento, 30
Vimercate
Italy
Email: pietro_vittorio.grandi@alcatel-lucent.com
Rajan Rao Rajan Rao
Infinera Corporation Infinera Corporation
169, Java Drive 140, Caspian CT.
Sunnyvale, CA-94089 Sunnyvale, CA-94089
USA USA
Email: rrao@infinera.com Email: rrao@infinera.com
Khuzema Pithewan
Infinera Corporation
169, Java Drive
Sunnyvale, CA-94089
USA
Email: kpithewan@infinera.com
John E Drake John E Drake
Juniper Juniper
Email: jdrake@juniper.net Email: jdrake@juniper.net
 End of changes. 32 change blocks. 
64 lines changed or deleted 67 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/