idnits 2.17.1
draft-awduche-mpls-te-optical-02.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Looks like you're using RFC 2026 boilerplate. This must be updated to
follow RFC 3978/3979, as updated by RFC 4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
** The document seems to lack a 1id_guidelines paragraph about 6 months
document validity -- however, there's a paragraph with a matching
beginning. Boilerplate error?
** The document is more than 15 pages and seems to lack a Table of Contents.
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
Miscellaneous warnings:
----------------------------------------------------------------------------
== Line 444 has weird spacing: '... of the netwo...'
== Line 582 has weird spacing: '...tuation may b...'
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (July 2000) is 8685 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Missing reference section? '1' on line 861 looks like a reference
-- Missing reference section? '2' on line 865 looks like a reference
-- Missing reference section? '3' on line 868 looks like a reference
-- Missing reference section? '4' on line 872 looks like a reference
-- Missing reference section? '8' on line 884 looks like a reference
-- Missing reference section? '9' on line 887 looks like a reference
-- Missing reference section? '10' on line 890 looks like a reference
-- Missing reference section? '5' on line 875 looks like a reference
-- Missing reference section? '12' on line 896 looks like a reference
-- Missing reference section? '13' on line 899 looks like a reference
-- Missing reference section? '6' on line 877 looks like a reference
-- Missing reference section? '7' on line 881 looks like a reference
-- Missing reference section? '11' on line 893 looks like a reference
-- Missing reference section? 'RSVP' on line 615 looks like a reference
-- Missing reference section? '14' on line 903 looks like a reference
-- Missing reference section? '15' on line 906 looks like a reference
Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 18 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 Internet Engineering Task Force
2 INTERNET-DRAFT
3 Daniel O. Awduche
4 Expiration Date: January 2001 UUNET (Worldcom)
6 Yakov Rekhter
7 Cisco Systems
9 John Drake
10 Calient Networks
12 Rob Coltun
13 Redback Networks
14 July 2000
16 Multi-Protocol Lambda Switching:
17 Combining MPLS Traffic Engineering Control With Optical Crossconnects
19 draft-awduche-mpls-te-optical-02.txt
21 Status of this Memo
23 This document is an Internet-Draft and is in full conformance with
24 all provisions of Section 10 of RFC2026 except that the right to
25 produce derivative works is not granted.
27 Internet-Drafts are working documents of the Internet Engineering
28 Task Force (IETF), its areas, and its working groups. Note that
29 other groups may also distribute working documents as Internet-
30 Drafts.
32 Internet-Drafts are draft documents valid for a maximum of six months
33 and may be updated, replaced, or obsoleted by other documents at any
34 time. It is inappropriate to use Internet- Drafts as reference
35 material or to cite them other than as "work in progress."
37 The list of current Internet-Drafts can be accessed at
38 http://www.ietf.org/ietf/1id-abstracts.txt
40 The list of Internet-Draft Shadow Directories can be accessed at
41 http://www.ietf.org/shadow.html.
43 Abstract
45 This document describes an approach to the design of control planes
46 for optical crossconnects (OXCs), which leverages existing control
47 plane techniques developed for MPLS Traffic Engineering. The
48 proposed approach combines recent advances in MPLS traffic
49 engineering control plane constructs with OXC technology to: (1)
50 provide a framework for real-time provisioning of optical channels in
51 automatically switched optical networks, (2) foster the expedited
52 development and deployment of a new class of versatile OXCs, and (3)
53 allow the use of uniform semantics for network management and
54 operations control in hybrid networks consisting of OXCs and label
55 switching routers (LSRs). The proposed approach is particularly
56 advantageous for OXCs intended for data-centric optical
57 internetworking systems. In such environments, it will help to
58 simplify network administration. This approach also paves the way
59 for the eventual incorporation of DWDM multiplexing capabilities in
60 IP routers.
62 1. Introduction
64 This document describes an approach to the design of control planes
65 for optical crossconnects (OXCs), which is based on the Multiprotocol
66 Label Switching (MPLS) traffic engineering control plane model. In
67 this approach, the main idea it to leverage recent advances in
68 control plane technology developed for MPLS traffic engineering (see
69 [1,2,3,4,8,9,10]). This approach is driven by pragmatic
70 considerations, as it exploits an existing technology base to foster
71 rapid development and deployment of a new class of versatile OXCs
72 that address the optical transport needs of the rapidly evolving
73 Internet. This approach will assist in optical channel layer
74 bandwidth management, dynamic provisioning of optical channels, and
75 network survivability through enhanced protection and restoration
76 capabilities in the optical domain.
78 As used in this document, an OXC is a path switching element in an
79 optical transport network that establishes routed paths for optical
80 channels by locally connecting an optical channel from an input port
81 (fiber) to an output port (fiber) on the switch element. Additional
82 characteristics of OXCs, as used in this document, are discussed in
83 Section 4.1.
85 The proposed OXC control plane uses the IGP extensions for MPLS
86 traffic engineering (with additional enhancements) to distribute
87 relevant optical transport network state information, including
88 topology state information. This state information is subsequently
89 used by a constraint-based routing system to compute paths for
90 point-to-point optical channels through the optical transport
91 network. The proposed OXC control plane also uses an MPLS signaling
92 protocol (see [3,4]) to instantiate point-to-point optical channels
93 between access points in the optical transport network.
95 This document does not specify the details of the extensions and
96 domain specific adaptations required to map the MPLS traffic
97 engineering control plane model onto the optical domain. These
98 aspects will be covered in a number of supplementary documents that
99 will follow. However, in Section 7 of this memo, we provide a high
100 level overview of the architectural issues involved in making such
101 adaptations.
103 2. Advantages
105 The advantages of the proposed approach are numerous.
107 - It offers a framework for optical bandwidth management
108 and the real-time provisioning of optical channels in
109 automatically switched optical networks.
111 - It exploits recent advances in MPLS control plane technology
112 and also leverages accumulated operational experience with IP
113 distributed routing control.
115 - It obviates the need to reinvent a new class of control
116 protocols for optical transport networks and allows reuse
117 of software artifacts originally developed for the MPLS
118 traffic engineering application. Consequently, it fosters
119 the rapid development and deployment of a new class of
120 versatile OXCs.
122 - It facilitates the introduction of control coordination concepts
123 between data network elements and optical network elements.
125 - It simplifies network administration in facilities based service
126 provider networks by providing uniform semantics for network
127 management and control in both the data and optical domains.
129 - It paves the way for the eventual introduction of DWDM
130 multiplexing capabilities on IP routers
132 - Lastly, it establishes a preliminary framework for the notion
133 of an optical Internet.
135 3. Background
137 The growth, performance, and survivability requirements of the
138 Internet (which is also becoming very mission critical) are mandating
139 IP-centric networks to be cost effective, survivable, scalable, and
140 to provide control capabilities that facilitate network performance
141 optimization. Some of these requirements are being addressed by the
142 Multiprotocol Label Switching (MPLS) traffic engineering capabilities
143 under development by the IETF [1,2,3,4].
145 The underlying optical transport network also needs to be versatile,
146 reconfigurable, cost effective, and to support a variety of
147 protection and restoration capabilities due to the rapidly changing
148 requirements of the Internet.
150 A result of these trends, therefore, is the evolution of optical
151 transport networks from simple linear and ring topologies to mesh
152 topologies. By a mesh (not necessarily fully meshed) topology, we
153 mean a connected (not necessarily fully connected) network of
154 arbitrary topology in which the node degree is typically more than
155 two. In mesh optical networks, optical crossconnects engender
156 versatility and reconfigurability by performing switching and
157 rearrangement functions.
159 Underscoring the importance of versatile networking capabilities in
160 the optical domain, a number of standardization organizations and
161 interoperability forums have initiated work items to study the
162 requirements and architectures for reconfigurable optical networks.
163 Refer, for example, to ITU-T recommendation G.872 [5]. This document
164 defines a functional architecture for an optical transport network
165 (OTN) that supports the transport of digital client signals. ITU-T
166 G.872 speaks of an OTN as "a transport network bounded by optical
167 channel access points"[5]. The ITU-T G.872 OTN architecture is based
168 on a layered structure, which includes:
170 (a) an optical channel (OCh) layer network,
171 (b) an optical multiplex section (OMS) layer network, and
172 (c) an optical transmission section (OTS) layer network.
174 The optical channel layer is the most relevant to the discussions in
175 this document. The optical channel layer network supports end-to-end
176 networking of optical channel trails between access points. The OCh
177 layer network provides the following functions: routing, monitoring,
178 grooming, and protection and restoration of optical channels. In
179 this situation, programmable Optical crossconnects, with
180 rearrangeable switch fabrics and relatively smart control planes,
181 will be critical to the realization of the OCh layer functions,
182 especially in mesh optical networks. In the data network domain,
183 routing, monitoring, and survivability are crucial functions
184 performed by the MPLS traffic engineering control plane (see
185 [1,2,3,4,8,9,10]).
187 Note: Although we mention the ITU-T recommendation G.872, the OXC
188 control plane design approach described here is not restricted to
189 G.872 compliant networks. Instead, it can be applied to any mesh
190 optical network that uses programmable and reconfigurable OXCs.
192 Other standards organizations and interoperability forums that are
193 actively pursuing projects related to dynamically reconfigurable
194 optical networks include the ANSI T1X1.5 committee, the Optical
195 Internetworking Forum (OIF), and now by virtue of this memo the IETF.
197 Recent contributions to ANSI T1X1.5 emphasize the need for automation
198 of the OCh layer network by using appropriate signaling protocols to
199 establish optical channels in real time (see [12] and [13]).
201 The Optical Internetworking Forum (http://www.oiforum.com), an
202 international organization engaged in the development and promotion
203 of interoperability agreements for optical internetworking systems,
204 is also evaluating architectural and signaling options related to the
205 internetworking of data network elements with reconfigurable optical
206 networks -- to facilitate rapid provisioning, efficient
207 protection/restoration, and other services in optical internetworking
208 systems.
210 In all these cases, the successful realization of the vision of
211 versatile optical networking depends very much on the synthesis of
212 appropriate control plane technologies with programmable and
213 reconfigurable OXCs.
215 4. OXCs, LSRs, Optical Trails, and Explicit LSPs
217 Consider a hybrid, IP-centric optical internetworking environment
218 consisting of both label switching routers (LSRs) and OXCs, where the
219 OXCs are programmable and support wavelength conversion/translation.
221 At a level of abstraction, an LSR and an OXC exhibit a number of
222 isomorphic relations. It is important to enumerate these relations
223 because they help to expose the reusable software artifacts from the
224 MPLS traffic engineering control plane model. Architecturally, both
225 LSRs and OXCs emphasize problem decomposition by decoupling the
226 control plane from the data plane.
228 The data plane of an LSR uses the label swapping paradigm to transfer
229 a labeled packet from an input port to an output port (see e.g.,
231 [6,7]). The data plane of an OXC uses a switching matrix to connect
232 an optical channel trail from an input port to an output port.
234 An LSR performs label switching by first establishing a relation
235 between an tuple and an