idnits 2.17.1
draft-awduche-mpls-te-optical-03.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
== The page length should not exceed 58 lines per page, but there was 1
longer page, the longest (page 1) being 61 lines
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 445 has weird spacing: '... of the netwo...'
== Line 583 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 (April 2001) is 8384 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 862 looks like a reference
-- Missing reference section? '2' on line 866 looks like a reference
-- Missing reference section? '3' on line 869 looks like a reference
-- Missing reference section? '4' on line 873 looks like a reference
-- Missing reference section? '8' on line 885 looks like a reference
-- Missing reference section? '9' on line 888 looks like a reference
-- Missing reference section? '10' on line 891 looks like a reference
-- Missing reference section? '5' on line 876 looks like a reference
-- Missing reference section? '12' on line 897 looks like a reference
-- Missing reference section? '13' on line 900 looks like a reference
-- Missing reference section? '6' on line 878 looks like a reference
-- Missing reference section? '7' on line 882 looks like a reference
-- Missing reference section? '11' on line 894 looks like a reference
-- Missing reference section? 'RSVP' on line 616 looks like a reference
-- Missing reference section? '14' on line 904 looks like a reference
-- Missing reference section? '15' on line 907 looks like a reference
Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 18 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Internet Engineering Task Force
3 INTERNET-DRAFT
4 Daniel O. Awduche
5 Expiration Date: October 2001 Movaz Networks
7 Yakov Rekhter
8 Juniper Networks
10 John Drake
11 Calient Networks
13 Rob Coltun
14 Redback Networks
15 April 2001
17 Multi-Protocol Lambda Switching:
18 Combining MPLS Traffic Engineering Control With Optical Crossconnects
20 draft-awduche-mpls-te-optical-03.txt
22 Status of this Memo
24 This document is an Internet-Draft and is in full conformance with
25 all provisions of Section 10 of RFC2026 except that the right to
26 produce derivative works is not granted.
28 Internet-Drafts are working documents of the Internet Engineering
29 Task Force (IETF), its areas, and its working groups. Note that
30 other groups may also distribute working documents as Internet-
31 Drafts.
33 Internet-Drafts are draft documents valid for a maximum of six months
34 and may be updated, replaced, or obsoleted by other documents at any
35 time. It is inappropriate to use Internet- Drafts as reference
36 material or to cite them other than as "work in progress."
38 The list of current Internet-Drafts can be accessed at
39 http://www.ietf.org/1id-abstracts.html
41 The list of Internet-Draft Shadow Directories can be accessed at
42 http://www.ietf.org/shadow.html.
44 Abstract
46 This document describes an approach to the design of control planes
47 for optical crossconnects (OXCs), which leverages existing control
48 plane techniques developed for MPLS Traffic Engineering. The
49 proposed approach combines recent advances in MPLS traffic
50 engineering control plane constructs with OXC technology to: (1)
51 provide a framework for real-time provisioning of optical channels in
52 automatically switched optical networks, (2) foster the expedited
53 development and deployment of a new class of versatile OXCs, and (3)
54 allow the use of uniform semantics for network management and
55 operations control in hybrid networks consisting of OXCs and label
56 switching routers (LSRs). The proposed approach is particularly
57 advantageous for OXCs intended for data-centric optical
58 internetworking systems. In such environments, it will help to
59 simplify network administration. This approach also paves the way
60 for the eventual incorporation of DWDM multiplexing capabilities in
61 IP routers.
63 1. Introduction
65 This document describes an approach to the design of control planes
66 for optical crossconnects (OXCs), which is based on the Multiprotocol
67 Label Switching (MPLS) traffic engineering control plane model. In
68 this approach, the main idea is to leverage recent advances in
69 control plane technology developed for MPLS traffic engineering (see
70 [1,2,3,4,8,9,10]). This approach is driven by pragmatic
71 considerations, as it exploits an existing technology base to foster
72 rapid development and deployment of a new class of versatile OXCs
73 that address the optical transport needs of the rapidly evolving
74 Internet. This approach will assist in optical channel layer
75 bandwidth management, dynamic provisioning of optical channels, and
76 network survivability through enhanced protection and restoration
77 capabilities in the optical domain.
79 As used in this document, an OXC is a path switching element in an
80 optical transport network that establishes routed paths for optical
81 channels by locally connecting an optical channel from an input port
82 (fiber) to an output port (fiber) on the switch element. Additional
83 characteristics of OXCs, as used in this document, are discussed in
84 Section 4.1.
86 The proposed OXC control plane uses the IGP extensions for MPLS
87 traffic engineering (with additional enhancements) to distribute
88 relevant optical transport network state information, including
89 topology state information. This state information is subsequently
90 used by a constraint-based routing system to compute paths for
91 point-to-point optical channels through the optical transport
92 network. The proposed OXC control plane also uses an MPLS signaling
93 protocol (see [3,4]) to instantiate point-to-point optical channels
94 between access points in the optical transport network.
96 This document does not specify the details of the extensions and
97 domain specific adaptations required to map the MPLS traffic
98 engineering control plane model onto the optical domain. These
99 aspects will be covered in a number of supplementary documents that
100 will follow. However, in Section 7 of this memo, we provide a high
101 level overview of the architectural issues involved in making such
102 adaptations.
104 2. Advantages
106 The advantages of the proposed approach are numerous.
108 - It offers a framework for optical bandwidth management
109 and the real-time provisioning of optical channels in
110 automatically switched optical networks.
112 - It exploits recent advances in MPLS control plane technology
113 and also leverages accumulated operational experience with IP
114 distributed routing control.
116 - It obviates the need to reinvent a new class of control
117 protocols for optical transport networks and allows reuse
118 of software artifacts originally developed for the MPLS
119 traffic engineering application. Consequently, it fosters
120 the rapid development and deployment of a new class of
121 versatile OXCs.
123 - It facilitates the introduction of control coordination concepts
124 between data network elements and optical network elements.
126 - It simplifies network administration in facilities based service
127 provider networks by providing uniform semantics for network
128 management and control in both the data and optical domains.
130 - It paves the way for the eventual introduction of DWDM
131 multiplexing capabilities on IP routers
133 - Lastly, it establishes a preliminary framework for the notion
134 of an optical Internet.
136 3. Background
138 The growth, performance, and survivability requirements of the
139 Internet (which is also becoming very mission critical) are mandating
140 IP-centric networks to be cost effective, survivable, scalable, and
141 to provide control capabilities that facilitate network performance
142 optimization. Some of these requirements are being addressed by the
143 Multiprotocol Label Switching (MPLS) traffic engineering capabilities
144 under development by the IETF [1,2,3,4].
146 The underlying optical transport network also needs to be versatile,
147 reconfigurable, cost effective, and to support a variety of
148 protection and restoration capabilities due to the rapidly changing
149 requirements of the Internet.
151 A result of these trends, therefore, is the evolution of optical
152 transport networks from simple linear and ring topologies to mesh
153 topologies. By a mesh (not necessarily fully meshed) topology, we
154 mean a connected (not necessarily fully connected) network of
155 arbitrary topology in which the node degree is typically more than
156 two. In mesh optical networks, optical crossconnects engender
157 versatility and reconfigurability by performing switching and
158 rearrangement functions.
160 Underscoring the importance of versatile networking capabilities in
161 the optical domain, a number of standardization organizations and
162 interoperability forums have initiated work items to study the
163 requirements and architectures for reconfigurable optical networks.
164 Refer, for example, to ITU-T recommendation G.872 [5]. This document
165 defines a functional architecture for an optical transport network
166 (OTN) that supports the transport of digital client signals. ITU-T
167 G.872 speaks of an OTN as "a transport network bounded by optical
168 channel access points"[5]. The ITU-T G.872 OTN architecture is based
169 on a layered structure, which includes:
171 (a) an optical channel (OCh) layer network,
172 (b) an optical multiplex section (OMS) layer network, and
173 (c) an optical transmission section (OTS) layer network.
175 The optical channel layer is the most relevant to the discussions in
176 this document. The optical channel layer network supports end-to-end
177 networking of optical channel trails between access points. The OCh
178 layer network provides the following functions: routing, monitoring,
179 grooming, and protection and restoration of optical channels. In
180 this situation, programmable Optical crossconnects, with
181 rearrangeable switch fabrics and relatively smart control planes,
182 will be critical to the realization of the OCh layer functions,
183 especially in mesh optical networks. In the data network domain,
184 routing, monitoring, and survivability are crucial functions
185 performed by the MPLS traffic engineering control plane (see
186 [1,2,3,4,8,9,10]).
188 Note: Although we mention the ITU-T recommendation G.872, the OXC
189 control plane design approach described here is not restricted to
190 G.872 compliant networks. Instead, it can be applied to any mesh
191 optical network that uses programmable and reconfigurable OXCs.
193 Other standards organizations and interoperability forums that are
194 actively pursuing projects related to dynamically reconfigurable
195 optical networks include the ANSI T1X1.5 committee, the Optical
196 Internetworking Forum (OIF), and now by virtue of this memo the IETF.
198 Recent contributions to ANSI T1X1.5 emphasize the need for automation
199 of the OCh layer network by using appropriate signaling protocols to
200 establish optical channels in real time (see [12] and [13]).
202 The Optical Internetworking Forum (http://www.oiforum.com), an
203 international organization engaged in the development and promotion
204 of interoperability agreements for optical internetworking systems,
205 is also evaluating architectural and signaling options related to the
206 internetworking of data network elements with reconfigurable optical
207 networks -- to facilitate rapid provisioning, efficient
208 protection/restoration, and other services in optical internetworking
209 systems.
211 In all these cases, the successful realization of the vision of
212 versatile optical networking depends very much on the synthesis of
213 appropriate control plane technologies with programmable and
214 reconfigurable OXCs.
216 4. OXCs, LSRs, Optical Trails, and Explicit LSPs
218 Consider a hybrid, IP-centric optical internetworking environment
219 consisting of both label switching routers (LSRs) and OXCs, where the
220 OXCs are programmable and support wavelength conversion/translation.
222 At a level of abstraction, an LSR and an OXC exhibit a number of
223 isomorphic relations. It is important to enumerate these relations
224 because they help to expose the reusable software artifacts from the
225 MPLS traffic engineering control plane model. Architecturally, both
226 LSRs and OXCs emphasize problem decomposition by decoupling the
227 control plane from the data plane.
229 The data plane of an LSR uses the label swapping paradigm to transfer
230 a labeled packet from an input port to an output port (see e.g.,
232 [6,7]). The data plane of an OXC uses a switching matrix to connect
233 an optical channel trail from an input port to an output port.
235 An LSR performs label switching by first establishing a relation
236 between an tuple and an