CCAMP Working Group D. Ceccarelli
Internet-Draft D. Caviglia
Intended status: Standards Track Ericsson
Expires: September 15, 2011 F. Zhang
D. Li
Huawei Technologies
Y. Xu
CATR
S. Belotti
P. Grandi
Alcatel-Lucent
R. Rao
Infinera Corporation
J. Drake
Juniper
March 14, 2011
Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS)
Control of Evolving G.709 OTN Networks
draft-ceccarelli-ccamp-gmpls-ospf-g709-05
Abstract
The recent revision of ITU-T Recommendation G.709 [G709-V3] has
introduced new fixed and flexible ODU containers, enabling optimized
support for an increasingly abundant service mix.
This document describes OSPF routing protocol extensions to support
Generalized MPLS (GMPLS) control of all currently defined ODU
containers, in support of both sub-lambda and lambda level routing
granularity.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
Ceccarelli, et al. Expires September 15, 2011 [Page 1]
Internet-Draft OSPF-TE extensions for OTN support March 2011
This Internet-Draft will expire on September 15, 2011.
Copyright Notice
Copyright (c) 2011 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Ceccarelli, et al. Expires September 15, 2011 [Page 2]
Internet-Draft OSPF-TE extensions for OTN support March 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. OSPF Extensions . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. ISCD extensions . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Unreserved Bandwidth sub-sub-TLV . . . . . . . . . . . 5
2.2. IMCD - Interface Multiplexing Capability Descriptor . . . 6
2.2.1. IMCD Bandwidth sub-sub-TLV . . . . . . . . . . . . . . 7
3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. ODUk advertisement . . . . . . . . . . . . . . . . . . . . 10
3.2. ODUj advertisement . . . . . . . . . . . . . . . . . . . . 10
3.3. Link Bundling . . . . . . . . . . . . . . . . . . . . . . 10
4. Optimization considerations . . . . . . . . . . . . . . . . . 11
4.1. Efficient priorities advertisement . . . . . . . . . . . . 11
4.2. Efficient bandwidth encoding . . . . . . . . . . . . . . . 12
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Ceccarelli, et al. Expires September 15, 2011 [Page 3]
Internet-Draft OSPF-TE extensions for OTN support March 2011
1. Introduction
G.709 OTN [G709-V3] includes new fixed and flexible ODU containers,
two types of Tributary Slots (i.e., 1.25Gbps and 2.5Gbps), and
supports various multiplexing relationships (e.g., ODUj multiplexed
into ODUk (j<k)), two different tributary slots for ODUk (K=1, 2, 3)
and ODUflex service type, which is being standardized in ITU-T. In
order to present this information in the routing process, this
document provides OTN technology specific encoding for OSPF-TE.
For a short overview of OTN evolution and implications of OTN
requirements on GMPLS routing please refer to [OTN-FWK]. The
information model and an evaluation against the current solution are
provided in [OTN-INFO].
The routing information for Optical Channel Layer (OCh) (i.e.,
wavelength) is out of the scope of this document. Please refer to
[WSON-Frame] for further information.
1.1. 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].
2. OSPF Extensions
In terms of GMPLS based OTN networks, each OTUk can be viewed as a
component link, and each component link can carry one or more types
of ODUj (j<k).
Each TE LSA can carry a top-level link TLV with several nested sub-
TLVs to describe different attributes of a TE link. Two top-level
TLVs are defined in [RFC 3630]. (1) The Router Address TLV (referred
to as the Node TLV) 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 also defined in [RFC 3630] and [RFC 4203].
As discussed in [OTN-FWK] and [OTN-INFO], the OSPF-TE must be
extended so to be able to advertise the termination and switching
capabilites related to each different ODUj and ODUk and the
advertisement of related multiplexing capabilities. This document
defines:
- New Switching Capability and Encoding Type values for the ISCD
with related new sub-sub-TLVs
Ceccarelli, et al. Expires September 15, 2011 [Page 4]
Internet-Draft OSPF-TE extensions for OTN support March 2011
- A new Link type sub-TLV called IMCD with related sub-sub-TLVs
In the following we will use ODUj to indicate a service type that is
multiplexed into an higher order ODU and ODUk to indicate the layer
mapped into the OTUk. Moreover ODUj(S) and ODUk(S) are used to
indicate ODUj and ODUk with switching capability only, ODUj(T) and
ODUk(T) to indicate ODUj and ODUk with terminating capability only
and ODUj(T,S) and ODUk(T,S) to indicate ODUj and ODUk that can be
both switched or terminated. Moreover the ODUj->ODUk format is used
to indicate the ODUj into ODUk multiplexing capability.
The advertisement of available bandwidth, max LSP bandwidth and
multiplexing capabilities is performed as follows:
- ODUk(S) advertised in the ISCD
- ODUk(T) advertised in the IMCD (Interface Multiplexing
Capability Descriptor)
- ODUk(T,S) advertised both in the ISCD and IMCD
- ODUj(*) and related multiplexing hierarchy advertised in the
IMCD
The IMCD and new sub-sub-TLVs format are illustrated in the following
sections.
2.1. ISCD extensions
This document defines a new Switching Capability value
Value Type
----- ----
101 OTN-TDM
while the values of the Encoding Type field are the ones defined in
[RFC4328].
2.1.1. Unreserved Bandwidth sub-sub-TLV
The Unreserved bandwidth sub-sub-TLV is included into the SCSI
(Switching Capability Specific Information) of the ISCD. It is used
for the advertisement of ODUk(S) unreserved bandwidth. Please note
that there is no need to advertise MAX LSP bandwidth within the ISCD
because the only container with variable bandwidth (ODUflex) can be
Ceccarelli, et al. Expires September 15, 2011 [Page 5]
Internet-Draft OSPF-TE extensions for OTN support March 2011
an ODUj only. The format of the Unreserved Bandwidth sub-sub-TLV is
shown in the following figure.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Available ODUk priority 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Available ODUk priority 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Available ODUk priority 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Available ODUk priority 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Available ODUk priority 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Available ODUk priority 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Available ODUk priority 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Available ODUk priority 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Unreserved Bandwidth sub-sub-TLV format
- Type: Type = 1 indicates Unreserved Bandwidth sub-sub-TLV. i.e.
advertising Unreserved Bandwidth for ODUk containers.
- Lengths: Expressed in Bytes and aligned to 32bits.
- Number of Available ODUk at Priority Px: Indicates the number of
Available ODUk al Priority Px that can be Switched in the
advertised TE Link.
2.2. IMCD - Interface Multiplexing Capability Descriptor
The Interface Multiplexing Capability Descriptor (IMCD) is a new Link
type sub-TLV (Type TBA by IANA) and is used for the advertisement of:
- ODUk Termination Unreserved Bandwidth
- ODUj Switching and Termination Unreserved Bandwidth with related
muxing hierarchy
Ceccarelli, et al. Expires September 15, 2011 [Page 6]
Internet-Draft OSPF-TE extensions for OTN support March 2011
- ODUj Switching and Termination MAX LSP Bandwidth with related
muxing hierarchy
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-sub-TLVs |
| (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: IMCD sub-TLV format
- Type: To be assigned by IANA.
- Length: Expressed in Bytes and aligned to 32bits.
- Sub-sub-TLVs: The body of the IMCD can include a variable number
of sub-sub-TLVs.
2.2.1. IMCD Bandwidth sub-sub-TLV
This document defines three types of IMCD Unreserved Bandwidth sub-
sub-TLVs:
- Type = 1, advertising the Unreserved Bandwidth of fixed
bandwidth containers (e.g. ODU2,ODU3)
- Type = 2, advertising the Unreserved Bandwidth of variable
bandwidth containers (e.g. ODUFlex)
- Type = 3, advertising the MAX LSP Bandwdith of variable
bandwidth containers (e.g. ODUFlex)
The format is shown in figure below:
Ceccarelli, et al. Expires September 15, 2011 [Page 7]
Internet-Draft OSPF-TE extensions for OTN support March 2011
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| G-PID |T|S| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwdith at Priority 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwdith at Priority 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwdith at Priority 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwdith at Priority 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwdith at Priority 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwdith at Priority 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwdith at Priority 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwdith at Priority 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IMCD Bandwidth sub-sub-TLV format
The rest of the sub-sub-TLV fields is defined as follows:
- Length: Expressed in Bytes and aligned to 32bits.
- G-PID: Defines new values in addition to those already defined
in RFC3471] and identifies the muxing hierarchy supported by a
component link.
Ceccarelli, et al. Expires September 15, 2011 [Page 8]
Internet-Draft OSPF-TE extensions for OTN support March 2011
Value G-PID
----- ------
100 ODU1
101 ODU2
102 ODU3
103 ODU4
104 ODU1->ODU0
105 ODU2->ODU0
106 ODU2->ODU1
107 ODU2->ODU1->ODU0
108 ODU2->ODUflex
109 ODU3->ODU0
110 ODU3->ODU1
111 ODU3->ODU1->ODU0
112 ODU3->ODU2
113 ODU3->ODU2->ODU0
114 ODU3->ODU2->ODU1
115 ODU3->ODU2->ODU1->ODU0
116 ODU3->ODU2->ODUflex
117 ODU3->ODUflex
118 ODU3->ODU2e
119 ODU4->ODU0
120 ODU4->ODU1
121 ODU4->ODU1->ODU0
122 ODU4->ODU2
123 ODU4->ODU2->ODU0
124 ODU4->ODU2->ODU1
125 ODU4->ODU2->ODU1->ODU0
126 ODU4->ODU2->ODUflex
127 ODU4->ODU3
128 ODU4->ODU3->ODU0
129 ODU4->ODU3->ODU1
130 ODU4->ODU3->ODU1->ODU0
131 ODU4->ODU3->ODU2
132 ODU4->ODU3->ODU2->ODU0
133 ODU4->ODU3->ODU2->ODU1
134 ODU4->ODU3->ODU2->ODU1->ODU0
135 ODU4->ODU3->ODU2->ODUflex
136 ODU4->ODU3->ODUflex
137 ODU4->ODU3->ODU2e
138 ODU4->ODUflex
139 ODU4->ODU2e
- Flags: T,S flags are used to indicate Termination and Switching
capabilities of the ODUj containers and MUST be set to 0 and
ignored in case of ODUk.
Ceccarelli, et al. Expires September 15, 2011 [Page 9]
Internet-Draft OSPF-TE extensions for OTN support March 2011
- Unreserved Bandwidth: Indicates the Unreserved bandwidth of the
container being advertised. It MUST be expressed in Number of
Available containers in case of fixed containers (i.e. Type=1)
and in IEEE floating point in case of variable bandwidth
containers (i.e. Type=2).
3. Procedures
3.1. ODUk advertisement
The advertisement of ODUk is performed via ISCD, IMCD or both,
depending on the terminating and switching capabilities of the given
ODUk. In case of ODUk(S), its unreserved bandwidth MUST be
advertised by means of the Unreserved Bandwidth sub-sub-TLV included
into the ISCD. One ISCD for each ODUk(S) is advertised.
On the other hand, an ODUk(T) MUST be advertised via the Bandwidth
sub-sub-TLV included into the IMCD. Multiple ODUk(T) MAY be
advertised withing the same IMCD.
In the case of ODUk(T,S), the advertisement of such ODUk MUST be
present both in the ISCD and the IMCD.
3.2. ODUj advertisement
The advertisement of ODUj MUST be performed via IMCD only and its
terminating and switching capabilities are specified by the flags (T
and S) of the Bandwidth sub-sub-TLV.
Unreserved and MAX LSP bandwidth are advertised by means of different
types of the Bandwdith sub-sub-TLV as shown in Section 2.2.1.
The advertisement of ODUj(S) is not performed via ISCD because the
ISCD does not provide the means for distinguishing between ODUj and
ODUk and this would prevent the bundling of interfaces at different
line rates.
3.3. Link Bundling
It is possible to bundle different interfaces with different line
rates, muxing hierarchies and termination/switching capabilities
except the case in which the end nodes of a TE link have ODUk at the
same line rate but different terminating/switching capabilities or
muxing hierarchies.
An example of this exemption is shown in figure below:
Ceccarelli, et al. Expires September 15, 2011 [Page 10]
Internet-Draft OSPF-TE extensions for OTN support March 2011
+------+ link A +------+
| A1+------------------+A2 |
| N1 B1+------------------+B2 N2 |
| | link B | |
+--+---+ +---+--+
Figure 4: Bundling not allowed
In case link A has interface A1 supporting ODUk (T) and A2 supporting
OUDk(S) and link B with interface B1 supporting the same ODUk(S) and
B2 supporting ODUk(T), the bundling of the two links in a single TE
link would give the false information of ODUk(S) availability at the
ends of the TE link. Hence, link A and link B cannot be bundled into
the same TE link.
4. Optimization considerations
Optimization considerations are extremely important not only under
the scalability point of view but also considering the requirement
that an LSA (Link State Advertisement) cannot be fragmented into
multiple IP packets. Considering that in a conforming Ethernet
environment the Frame_MTU is 1500 bytes, the amount of available
bandwidth for the LSA payload is 1432 byte. (1500 byte - (IP header
20bytes + OSPF header 28bytes + LSA header 20 bytes)). IP packets
fragmentation is not suggested in IPv4-IPv6 as it has a big impact on
computation efficiency and CPU processing time.
4.1. Efficient priorities advertisement
Actual GMPLS definition foresees the advertisement of all the eight
possible priorities. This is an inefficient approach in terms of
bandwidth utilization in those cases where not all the priorities are
supported. A possible enhancement consists on inserting an 8 bits
bitmask identifying the supported priorities being advertised.
The bitmask can be applied to the Unreserved Bandwidth sub-sub-TLV of
the ISCD and to the Bandwidth sub-sub-TLV of the IMCD. The following
figure shows an example of bitmask application to the Bandwidth sub-
sub-TLV in the advertisemnt of the MAX LSP bandwidth of a given
service type:
Ceccarelli, et al. Expires September 15, 2011 [Page 11]
Internet-Draft OSPF-TE extensions for OTN support March 2011
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| G-PID |T|S| |1|0|0|1|0|0|0|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth at Priority 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth at Priority 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth at Priority 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Efficient priorities advertisement
Only priorities 0,3 and 7 are supported and hence advertised. In
this simple example the amount of bytes saved is 20, but in a
scenario with traffic cards supporting a high number of service types
and muxing hierarchies, the amount of saved bandwidth is meaningful.
4.2. Efficient bandwidth encoding
When a fixed bandwidth service type is advertised, the number of
available service types is used as measurement units. This can be
esaily advertised via a 16 bits field instead of 32 bits (needed for
IEEE floating point encoding). When the number of supported
priorities is odd, padding to multiples of 32 bits is required. The
following figure shows an example of Unreserved Bandwidth
advertisement via Bandwidth sub-sub-TLV with 3 priorities supported
and padding.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| G-PID |T|S| |1|0|0|1|0|0|0|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth at Priority 0 | Bandwidth at Priority 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth at Priority 7 | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Efficient bandwidth encoding
Ceccarelli, et al. Expires September 15, 2011 [Page 12]
Internet-Draft OSPF-TE extensions for OTN support March 2011
5. Example
TBD
6. Compatibility
Backwards compatibility with implementations based on [RFC4328] can
be achieved advertising the [RFC4328] based ISCDs in addition to the
ISCD defined in this document.
7. Security Considerations
This document specifies the contents of Opaque LSAs in OSPFv2. As
Opaque LSAs are not used for SPF computation or normal routing, the
extensions specified here have no direct effect on IP routing.
Tampering with GMPLS TE LSAs may have an effect on the underlying
transport (optical and/or SONET-SDH) network. [RFC3630] suggests
mechanisms such as [RFC2154] to protect the transmission of this
information, and those or other mechanisms should be used to secure
and/or authenticate the information carried in the Opaque LSAs.
8. IANA Considerations
TBD
9. Contributors
Xiaobing Zi, Huawei Technologies
Email: zixiaobing@huawei.com
Francesco Fondelli, Ericsson
Email: francesco.fondelli@ericsson.com
Marco Corsi, Altran Italia
EMail: marco.corsi@altran.it
Ceccarelli, et al. Expires September 15, 2011 [Page 13]
Internet-Draft OSPF-TE extensions for OTN support March 2011
Eve Varma, Alcatel-Lucent
EMail: eve.varma@alcatel-lucent.com
Jonathan Sadler, Tellabs
EMail: jonathan.sadler@tellabs.com
Lyndon Ong, Ciena
EMail: lyong@ciena.com
Ashok Kunjidhapatham
akunjidhapatham@infinera.com
Snigdho Bardalai
sbardalai@infinera.com
Khuzema Pithewan
kpithewan@infinera.com
Steve Balls
Steve.Balls@metaswitch.com
Xihua Fu
fu.xihua@zte.com.cn
Ceccarelli, et al. Expires September 15, 2011 [Page 14]
Internet-Draft OSPF-TE extensions for OTN support March 2011
10. Acknowledgements
The authors would like to thank Eric Gray for his precious comments
and advices.
11. References
11.1. Normative References
[MLN-EXT] D.Papadimitriou, M.Vigoureux, K.Shiomoto, D.Brungard, J.Le
Roux, "Generalized Multi-Protocol Extensions for Multi-
Layer and Multi-Region Network (MLN/MRN)", February 2010.
[OTN-FWK] 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-02", July 2010.
[OTN-INFO]
S.Belotti, P.Grandi, D.Ceccarelli, D.Caviglia, F.Zhang,
D.Li, "Information model for G.709 Optical Transport
Networks (OTN), work in progress
draft-bddg-ccamp-otn-g709-info-model-01", October 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with
Digital Signatures", RFC 2154, June 1997.
[RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370,
July 1998.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
September 2003.
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, October 2005.
[RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support
of Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4203, October 2005.
Ceccarelli, et al. Expires September 15, 2011 [Page 15]
Internet-Draft OSPF-TE extensions for OTN support March 2011
[RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The
OSPF Opaque LSA Option", RFC 5250, July 2008.
[RFC5339] Le Roux, JL. and D. Papadimitriou, "Evaluation of Existing
GMPLS Protocols against Multi-Layer and Multi-Region
Networks (MLN/MRN)", RFC 5339, September 2008.
11.2. Informative References
[G.709] ITU-T, "Interface for the Optical Transport Network
(OTN)", G.709 Recommendation (and Amendment 1),
February 2001.
[G.709-v3]
ITU-T, "Draft revised G.709, version 3", consented
by ITU-T on Oct 2009.
[Gsup43] ITU-T, "Proposed revision of G.sup43 (for agreement)",
December 2008.
Authors' Addresses
Daniele Ceccarelli
Ericsson
Via A. Negrone 1/A
Genova - Sestri Ponente
Italy
Email: daniele.ceccarelli@ericsson.com
Diego Caviglia
Ericsson
Via A. Negrone 1/A
Genova - Sestri Ponente
Italy
Email: diego.caviglia@ericsson.com
Ceccarelli, et al. Expires September 15, 2011 [Page 16]
Internet-Draft OSPF-TE extensions for OTN support March 2011
Fatai Zhang
Huawei Technologies
F3-5-B R&D Center, Huawei Base
Shenzhen 518129 P.R.China Bantian, Longgang District
Phone: +86-755-28972912
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
Yunbin Xu
CATR
11 Yue Tan Nan Jie
Beijing
P.R.China
Email: xuyunbin@mail.ritt.com.cn
Sergio Belotti
Alcatel-Lucent
Via Trento, 30
Vimercate
Italy
Email: sergio.belotti@alcatel-lucent.com
Pietro Vittorio Grandi
Alcatel-Lucent
Via Trento, 30
Vimercate
Italy
Email: pietro_vittorio.grandi@alcatel-lucent.com
Ceccarelli, et al. Expires September 15, 2011 [Page 17]
Internet-Draft OSPF-TE extensions for OTN support March 2011
Rajan Rao
Infinera Corporation
169, Java Drive
Sunnyvale, CA-94089
USA
Email: rrao@infinera.com
John E Drake
Juniper
Email: jdrake@juniper.net
Ceccarelli, et al. Expires September 15, 2011 [Page 18]
