idnits 2.17.1
draft-awduche-mpls-te-optical-00.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 seems to lack a 1id_guidelines paragraph about the list of
current Internet-Drafts.
** The document seems to lack a 1id_guidelines paragraph about the list of
Shadow Directories.
** 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
== It seems as if not all pages are separated by form feeds - found 0 form
feeds but 19 pages
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 437 has weird spacing: '... of the netwo...'
-- 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 (October 1999) is 8959 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 755 looks like a reference
-- Missing reference section? '2' on line 759 looks like a reference
-- Missing reference section? '3' on line 762 looks like a reference
-- Missing reference section? '4' on line 766 looks like a reference
-- Missing reference section? '8' on line 778 looks like a reference
-- Missing reference section? '9' on line 781 looks like a reference
-- Missing reference section? '10' on line 784 looks like a reference
-- Missing reference section? '5' on line 769 looks like a reference
-- Missing reference section? '14' on line 796 looks like a reference
-- Missing reference section? '15' on line 799 looks like a reference
-- Missing reference section? '6' on line 771 looks like a reference
-- Missing reference section? '7' on line 775 looks like a reference
-- Missing reference section? '13' on line 793 looks like a reference
-- Missing reference section? '12' on line 790 looks like a reference
-- Missing reference section? 'RSVP' on line 573 looks like a reference
-- Missing reference section? '11' on line 787 looks like a reference
-- Missing reference section? '16' on line 803 looks like a reference
-- Missing reference section? '17' on line 806 looks like a reference
Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 20 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: April 2000 UUNET (MCI Worldcom)
5 Yakov Rekhter
6 Cisco Systems
7 John Drake
8 Fore Systems (Marconi)
9 Rob Coltun
10 Siara Systems
11 October 1999
13 Multi-Protocol Lambda Switching:
14 Combining MPLS Traffic Engineering Control With Optical Crossconnects
16 draft-awduche-mpls-te-optical-00.txt
18 Status of this Memo
20 This document is an Internet-Draft and is in full conformance with
21 all provisions of Section 10 of RFC2026 except that the right to
22 produce derivative works is not granted.
24 Internet-Drafts are working documents of the Internet Engineering
25 Task Force (IETF), its areas, and its working groups. Note that
26 other groups may also distribute working documents as Internet-
27 Drafts.
29 Internet-Drafts are draft documents valid for a maximum of six months
30 and may be updated, replaced, or obsoleted by other documents at any
31 time. It is inappropriate to use Internet- Drafts as reference
32 material or to cite them other than as "work in progress."
34 To view the list Internet-Draft Shadow Directories, see
35 http://www.ietf.org/shadow.html.
37 Abstract
39 This document describes an approach to the design of control planes
40 for optical crossconnects (OXCs), which leverages existing control
41 plane techniques developed for MPLS Traffic Engineering. The
42 proposed approach combines recent advances in MPLS traffic
43 engineering control plane constructs with OXC technology to: (1)
44 provide a framework for real-time provisioning of optical channels in
45 automatically switched optical networks, (2) foster the expedited
46 development and deployment of a new class of versatile OXCs, and (3)
47 allow the use of uniform semantics for network management and
48 operations control in hybrid networks consisting of OXCs and label
49 switching routers (LSRs). The proposed approach is particularly
50 advantageous for OXCs intended for data-centric optical
51 internetworking systems. In such environments, it will help to
52 simplify network administration. This approach also paves the way
53 for the eventual incorporation of DWDM multiplexing capabilities in
54 IP routers.
56 1. Introduction
58 This document describes an approach to the design of control planes
59 for optical crossconnects (OXCs), which is based on the Multiprotocol
60 Label Switching (MPLS) traffic engineering control plane model. In
61 this approach, the main idea it to leverage recent advances in
62 control plane technology developed for MPLS traffic engineering (see
63 [1,2,3,4,8,9,10]). This approach is driven by pragmatic
64 considerations, as it exploits an existing technology base to foster
65 rapid development and deployment of a new class versatile OXCs that
66 address the optical transport needs of the rapidly evolving Internet.
67 This approach will assist in optical channel layer bandwidth
68 management, dynamic provisioning of optical channels, and network
69 survivability through enhanced protection and restoration
70 capabilities in the optical domain.
72 As used in this document, an OXC is a path switching element in an
73 optical transport network that establishes routed paths for optical
74 channels by locally connecting an optical channel from an input port
75 (fiber) to an output port (fiber) on the switch element. Additional
76 characteristics of OXCs, as used in this document, are discussed in
77 Section 4.1.
79 The proposed OXC control plane uses the IGP extensions for MPLS
80 traffic engineering (with additional enhancements) to distribute
81 relevant optical transport network state information, including
82 topology state information. This state information is subsequently
83 used by a constraint-based routing system to compute paths for
84 point-to-point optical channels through the optical transport
85 network. The proposed OXC control plane also uses an MPLS signaling
86 protocol (see [3,4]) to instantiate point-to-point optical channels
87 between access points in the optical transport network.
89 This document does not specify the details of the extensions and
90 domain specific adaptations required to map the MPLS traffic
91 engineering control plane model onto the optical domain. These
92 aspects will be covered in a number of supplementary documents that
93 will follow. However, in Section 7 of this memo, we provide a high
94 level overview of the architectural issues involved in making such
95 adaptations.
97 2. Advantages
99 The advantages of the proposed approach are numerous.
101 - It offers a framework for optical bandwidth management
102 and the real-time provisioning of optical channels in
103 automatically switched optical networks.
105 - It exploits recent advances in MPLS control plane technology
106 and also leverages accumulated operational experience with IP
107 distributed routing control.
109 - It obviates the need to reinvent a new class of control
110 protocols for optical transport networks and allows reuse
111 of software artifacts originally developed for the MPLS
112 traffic engineering application. Consequently, it fosters
113 the rapid development and deployment of a new class of
114 versatile OXCs.
116 - It facilitates the introduction of control coordination concepts
117 between data network elements and optical network elements.
119 - It simples network administration in facilities based service
120 provider networks by providing uniform semantics for network
121 management and control in both the data and optical domains.
123 - It paves the way for the eventual introduction of DWDM
124 multiplexing capabilities on IP routers
126 - Lastly, it establishes a preliminary framework for the notion
127 of an optical Internet.
129 3. Background
131 The growth, performance, and survivability requirements of the
132 Internet (which is also becoming very mission critical) are mandating
133 IP-centric networks to be cost effective, survivable, scalable, and
134 to provide control capabilities that facilitate network performance
135 optimization. Some of these requirements are being addressed by the
136 Multiprotocol Label Switching (MPLS) traffic engineering capabilities
137 under development by the IETF [1,2,3,4].
139 The underlying optical transport network also needs to be versatile,
140 reconfigurable, cost effective, and to support a variety of
141 protection and restoration capabilities due to the rapidly changing
142 requirements of the Internet.
144 A result of these trends, therefore, is the evolution of optical
145 transport networks from simple linear and ring topologies to mesh
146 topologies. By a mesh (not necessarily fully meshed) topology, we
147 mean a connected (not necessarily fully connected) network of
148 arbitrary topology in which the node degree is typically more than
149 two. In mesh optical networks, optical crossconnects engender
150 versatility and reconfigurability by performing switching and
151 rearrangement functions.
153 Under-scoring the importance of versatile networking capabilities in
154 the optical domain, a number of standardization organizations and
155 interoperability forums have initiated work items to study the
156 requirements and architectures for reconfigurable optical networks.
157 Refer, for example, to ITU-T recommendation G.872 [5]. This document
158 defines a functional architecture for an optical transport network
159 (OTN) that supports the transport of digital client signals. ITU-T
160 G.872 speaks of an OTN as "a transport network bounded by optical
161 channel access points"[5]. The ITU-T G.872 OTN architecture is based
162 on a layered structure, which includes:
164 (a) an optical channel (OCh) layer network,
165 (b) an optical multiplex section (OMS) layer network, and
166 (c) an optical transmission section (OTS) layer network.
168 The optical channel layer is the most relevant to the discussions in
169 this document. The optical channel layer network supports end-to-end
170 networking of optical channel trails between access points. The OCh
171 layer network provides the following functions: routing, monitoring,
172 grooming, and protection and restoration of optical channels. In
173 this situation, programmable Optical crossconnects, with
174 rearrangeable switch fabrics and relatively smart control planes,
175 will be critical to the realization of the OCh layer functions,
176 especially in mesh optical networks. In the data network domain,
177 routing, monitoring, and survivability are crucial functions
178 performed by the MPLS traffic engineering control plane (see
179 [1,2,3,4,8,9,10]).
181 Note: Although we mention the ITU-T recommendation G.872, the OXC
182 control plane design approach described here is not restricted to
183 G.872 compliant networks. Instead, it can be applied to any mesh
184 optical network that uses programmable and reconfigurable OXCs.
186 Other standards organizations and interoperability forums that are
187 actively pursuing projects related to dynamically reconfigurable
188 optical networks include the ANSI T1X1.5 committee, the Optical
189 Internetworking Forum (OIF), and now by virtue of this memo the IETF.
191 Recent contributions to ANSI T1X1.5 emphasize the need for automation
192 of the OCh layer network by using appropriate signaling protocols to
193 establish optical channels in real time (see [14] and [15]).
195 The Optical Internetworking Forum (http://www.oiforum.com), an
196 international organization engaged in the development and promotion
197 of interoperability agreements for optical internetworking systems,
198 is also evaluating architectural options related to reconfigurable
199 optical internetworks. At a technical meeting held in California on
200 October 19, 1999, the Architecture Working Group of the OIF adopted a
201 motion to define requirements for signaling protocols that allow
202 rapid provisioning and efficient restoration in optical
203 internetworking systems.
205 In all these cases, the successful realization of the vision of
206 versatile optical networking depends very much on the synthesis of
207 appropriate control plane technologies with programmable and
208 reconfigurable OXCs.
210 4. OXCs, LSRs, Optical Trails, and Explicit LSPs
212 Consider a hybrid, IP-centric optical internetworking environment
213 consisting of both label switching routers (LSRs) and OXCs, where the
214 OXCs are programmable and support wavelength conversion/translation.
216 At a level of abstraction, an LSR and an OXC exhibit a number of
217 isomorphic relations. It is important to enumerate these relations
218 because they help to expose the reusable software artifacts from the
219 MPLS traffic engineering control plane model. Architecturally, both
220 LSRs and OXCs emphasize problem decomposition by decoupling the
221 control plane from the data plane.
223 The data plane of an LSR uses the label swapping paradigm to transfer
224 a labeled packet from an input port to an output port (see e.g.,
225 [6,7]). The data plane of an OXC uses a switching matrix to connect
226 an optical channel trail from an input port to an output port.
228 An LSR performs label switching by first establishing a relation
229 between an tuple and an