idnits 2.17.1 

draft-ietf-ccamp-gmpls-g709-framework-13.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

     No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust and authors Copyright Line does not
     match the current year

  -- The document date (June 18, 2013) is 3966 days in the past.  Is this
     intentional?


  Checking references for intended status: Informational
  ----------------------------------------------------------------------------

     No issues found here.

     Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.
--------------------------------------------------------------------------------

1	Network Working Group                                   Fatai Zhang, Ed.
2	Internet Draft                                                    Dan Li
3	Category: Informational                                           Huawei
4	                                                                  Han Li
5	                                                                    CMCC
6	                                                               S.Belotti
7	                                                          Alcatel-Lucent
8	                                                           D. Ceccarelli
9	                                                                Ericsson
10	Expires: December 18, 2013                                 June 18, 2013

12	                 Framework for GMPLS and PCE Control of
13	                    G.709 Optical Transport Networks

15	               draft-ietf-ccamp-gmpls-g709-framework-13.txt

17	Status of this Memo

19	   This Internet-Draft is submitted to IETF in full conformance with
20	   the provisions of BCP 78 and BCP 79.

22	   Internet-Drafts are working documents of the Internet Engineering
23	   Task Force (IETF), its areas, and its working groups.  Note that
24	   other groups may also distribute working documents as Internet-
25	   Drafts.

27	   Internet-Drafts are draft documents valid for a maximum of six months
28	   and may be updated, replaced, or obsoleted by other documents at any
29	   time.  It is inappropriate to use Internet-Drafts as reference
30	   material or to cite them other than as "work in progress."

32	   The list of current Internet-Drafts can be accessed at
33	   http://www.ietf.org/ietf/1id-abstracts.txt.

35	   The list of Internet-Draft Shadow Directories can be accessed at
36	   http://www.ietf.org/shadow.html.

38	   This Internet-Draft will expire on December 18, 2013.

40	Abstract

42	   This document provides a framework to allow the development of
43	   protocol extensions to support Generalized Multi-Protocol Label
44	   Switching (GMPLS) and Path Computation Element (PCE) control of
45	   Optical Transport Networks (OTN) as specified in ITU-T Recommendation
46	   G.709 as published in 2012.

48	Table of Contents

50	   1. Introduction .................................................. 2
51	   2. Terminology ................................................... 3
52	   3. G.709 Optical Transport Network ............................... 4
53	      3.1. OTN Layer Network ........................................ 4
54	         3.1.1. Client signal mapping ............................... 5
55	         3.1.2. Multiplexing ODUj onto Links ........................ 6
56	            3.1.2.1. Structure of MSI information ................... 8
57	   4. Connection management in OTN .................................. 9
58	      4.1. Connection management of the ODU ........................ 10
59	   5. GMPLS/PCE Implications ....................................... 12
60	      5.1. Implications for Label Switch Path (LSP) Hierarchy ...... 12
61	      5.2. Implications for GMPLS Signaling ........................ 13
62	      5.3. Implications for GMPLS Routing .......................... 15
63	      5.4. Implications for Link Management Protocol ............... 17
64	      5.5. Implications for Control Plane Backward Compatibility ... 18
65	      5.6. Implications for Path Computation Elements .............. 19
66	   6. Data Plane Backward Compatibility Considerations ............. 19
67	   7. Security Considerations ...................................... 20
68	   8. IANA Considerations .......................................... 21
69	   9. Acknowledgments .............................................. 21
70	   10. References .................................................. 21
71	      10.1. Normative References ................................... 21
72	      10.2. Informative References ................................. 22
73	   11. Authors' Addresses .......................................... 23
74	   12. Contributors ................................................ 24

76	1. Introduction

78	   OTN has become a mainstream layer 1 technology for the transport
79	   network. Operators want to introduce control plane capabilities based
80	   on GMPLS to OTN networks, to realize the benefits associated with a
81	   high-function control plane (e.g., improved network resiliency,
82	   resource usage efficiency, etc.).

84	   GMPLS extends Multi-Protocol Label Switching (MPLS) to encompass time
85	   division multiplexing (TDM) networks (e.g., Synchronous Optical
86	   NETwork (SONET)/ Synchronous Digital Hierarchy (SDH), Plesiochronous
87	   Digital Hierarchy (PDH), and G.709 sub-lambda), lambda switching
88	   optical networks, and spatial switching (e.g., incoming port or fiber
89	   to outgoing port or fiber). The GMPLS architecture is provided in
90	   [RFC3945], signaling function and Resource ReserVation Protocol-
91	   Traffic Engineering (RSVP-TE) extensions are described in [RFC3471]
92	   and [RFC3473], routing and Open Shortest Path First (OSPF) extensions
93	   are described in [RFC4202] and [RFC4203], and the Link Management
94	   Protocol (LMP) is described in [RFC4204].

96	   The GMPLS signaling extensions defined in [RFC4328] provide the
97	   mechanisms for basic GMPLS control of OTN networks based on the 2001
98	   revision of the G.709 specification. The 2012 revision of the G.709
99	   specification, [G709-2012], includes new features, for example,
100	   various multiplexing structures, two types of Tributary Slots (TSs)
101	   (i.e., 1.25Gbps and 2.5Gbps), and extension of the Optical channel
102	   Data Unit-j (ODUj) definition to include the ODUflex function.

104	   This document reviews relevant aspects of OTN technology evolution
105	   that affect the GMPLS control plane protocols and examines why and
106	   how to update the mechanisms described in [RFC4328]. This document
107	   additionally provides a framework for the GMPLS control of OTN
108	   networks and includes a discussion of the implication for the use of
109	   the PCE [RFC4655].

111	   For the purposes of the control plane the OTN can be considered as
112	   being comprised of ODU and wavelength (Optical Channel (OCh)) layers.
113	   This document focuses on the control of the ODU layer, with control
114	   of the wavelength layer considered out of the scope. Please refer to
115	   [RFC6163] for further information about the wavelength layer.

117	2. Terminology

119	   OTN: Optical Transport Network

121	   OPU: Optical channel Payload Unit

123	   ODU: Optical channel Data Unit

125	   OTU: Optical channel Transport Unit

127	   OMS: Optical multiplex section

129	   MSI: Multiplex Structure Identifier

131	   TPN: Tributary Port Number
132	   LO ODU: Lower Order ODU. The LO ODUj (j can be 0, 1, 2, 2e, 3, 4,
133	   flex.) represents the container transporting a client of the OTN that
134	   is either directly mapped into an OTUk (k = j) or multiplexed into a
135	   server HO ODUk (k > j) container.

137	   HO ODU: Higher Order ODU. The HO ODUk (k can be 1, 2, 2e, 3, 4.)
138	   represents the entity transporting a multiplex of LO ODUj tributary
139	   signals in its OPUk area.

141	   ODUflex: Flexible ODU. A flexible ODUk can have any bit rate and a
142	   bit rate tolerance of +/-100 ppm (parts per million).

144	3. G.709 Optical Transport Network

146	   This section provides an informative overview of those aspects of the
147	   OTN impacting control plane protocols.  This overview is based on the
148	   ITU-T Recommendations that contain the normative definition of the
149	   OTN. Technical details regarding OTN architecture and interfaces are
150	   provided in the relevant ITU-T Recommendations.

152	   Specifically, [G872-2012] describes the functional architecture of
153	   optical transport networks providing optical signal transmission,
154	   multiplexing, routing, supervision, performance assessment, and
155	   network survivability. The legacy OTN referenced by [RFC4328] defines
156	   the interfaces of the optical transport network to be used within and
157	   between subnetworks of the optical network.  With the evolution and
158	   deployment of OTN technology many new features have been specified in
159	   ITU-T recommendations, including for example, new ODU0, ODU2e, ODU4
160	   and ODUflex containers as described in [G709-2012].

162	3.1. OTN Layer Network

164	   The simplified signal hierarchy of OTN is shown in Figure 1, which
165	   illustrates the layers that are of interest to the control plane.
166	   Other layers below OCh (e.g. Optical Transmission Section (OTS)) are
167	   not included in this Figure. The full signal hierarchy is provided in
168	   [G709-2012].

170	                               Client signal
171	                                    |
172	                                   ODUj
173	                                    |
174	                                 OTU/OCh
175	                                   OMS

177	                   Figure 1 - Basic OTN signal hierarchy

179	   Client signals are mapped into ODUj containers. These ODUj containers
180	   are multiplexed onto the OTU/OCh. The individual OTU/OCh signals are
181	   combined in the OMS using Wavelength Division Multiplexing (WDM), and
182	   this aggregated signal provides the link between the nodes.

184	3.1.1. Client signal mapping

186	   The client signals are mapped into a LO ODUj. The current values of j
187	   defined in [G709-2012] are: 0, 1, 2, 2e, 3, 4, Flex. The approximate
188	   bit rates of these signals are defined in [G709-2012] and are
189	   reproduced in Tables 1 and 2.

191	                     Table 1 - ODU types and bit rates
192	   +-----------------------+-----------------------------------+
193	   |       ODU Type        |       ODU nominal bit rate        |
194	   +-----------------------+-----------------------------------+
195	   |         ODU0          |         1,244,160 Kbps            |
196	   |         ODU1          |    239/238 x 2,488,320 Kbps       |
197	   |         ODU2          |    239/237 x 9,953,280 Kbps       |
198	   |         ODU3          |    239/236 x 39,813,120 Kbps      |
199	   |         ODU4          |    239/227 x 99,532,800 Kbps      |
200	   |         ODU2e         |    239/237 x 10,312,500 Kbps      |
201	   |                       |                                   |
202	   |     ODUflex for       |                                   |
203	   |Constant Bit Rate (CBR)| 239/238 x client signal bit rate  |
204	   |    Client signals     |                                   |
205	   |                       |                                   |
206	   |   ODUflex for Generic |                                   |
207	   |   Framing Procedure   |        Configured bit rate        |
208	   |   - Framed (GFP-F)    |                                   |
209	   | Mapped client signal  |                                   |
210	   +-----------------------+-----------------------------------+

212	   NOTE - The nominal ODUk rates are approximately: 2,498,775.126 Kbps
213	   (ODU1), 10,037,273.924 Kbps (ODU2), 40,319,218.983 Kbps (ODU3),
214	   104,794,445.815 Kbps (ODU4) and 10,399,525.316 Kbps (ODU2e).

216	                     Table 2 - ODU types and tolerance
217	   +-----------------------+-----------------------------------+
218	   |      ODU Type         |       ODU bit-rate tolerance      |
219	   +-----------------------+-----------------------------------+
220	   |        ODU0           |            +/-20 ppm              |
221	   |        ODU1           |            +/-20 ppm              |
222	   |        ODU2           |            +/-20 ppm              |
223	   |        ODU3           |            +/-20 ppm              |
224	   |        ODU4           |            +/-20 ppm              |
225	   |        ODU2e          |            +/-100 ppm             |
226	   |                       |                                   |
227	   |   ODUflex for CBR     |                                   |
228	   |   Client signals      |            +/-100 ppm             |
229	   |                       |                                   |
230	   |  ODUflex for GFP-F    |                                   |
231	   | Mapped client signal  |            +/-100 ppm             |
232	   +-----------------------+-----------------------------------+

234	   One of two options is for mapping client signals into ODUflex
235	   depending on the client signal type:

237	   -  Circuit clients are proportionally wrapped. Thus the bit rate is
238	      defined by the client signal and the tolerance is fixed to +/-100
239	      ppm.

241	   -  Packet clients are mapped using the Generic Framing Procedure
242	      (GFP). [G709-2012] recommends that the ODUflex(GFP) will fill an
243	      integral number of tributary slots of the smallest HO ODUk path
244	      over which the ODUflex(GFP) may be carried, and the tolerance
245	      should be +/-100 ppm.

247	   Note that additional information on G.709 client mapping can be found
248	   in [G7041].

250	3.1.2. Multiplexing ODUj onto Links

252	   The links between the switching nodes are provided by one or more
253	   wavelengths.  Each wavelength carries one OCh, which carries one OTU,
254	   which carries one ODU.  Since all of these signals have a 1:1:1
255	   relationship, we only refer to the OTU for clarity.  The ODUjs are
256	   mapped into the TSs (Tributary Slots) of the OPUk.  Note that in the
257	   case where j=k the ODUj is mapped into the OTU/OCh without
258	   multiplexing.

260	   The initial versions of G.709 referenced by [RFC4328] only provided a
261	   single TS granularity, nominally 2.5Gbps. [G709-2012] added an
262	   additional TS granularity, nominally 1.25Gbps. The number and type of
263	   TSs provided by each of the currently identified OTUk is provided
264	   below:

266	             Tributary Slot Granularity
267	                2.5Gbps     1.25Gbps           Nominal Bit rate
268	     OTU1         1             2                  2.5Gbps
269	     OTU2         4             8                   10Gbps
270	     OTU3        16            32                   40Gbps
271	     OTU4        --            80                  100Gbps

273	   To maintain backwards compatibility while providing the ability to
274	   interconnect nodes that support 1.25Gbps TS at one end of a link and
275	   2.5Gbps TS at the other, [G709-2012] requires 'new' equipment fall
276	   back to the use of a 2.5Gbps TS when connected to legacy equipment.
277	   This information is carried in band by the payload type.

279	   The actual bit rate of the TS in an OTUk depends on the value of k.
280	   Thus the number of TSs occupied by an ODUj may vary depending on the
281	   values of j and k. For example an ODU2e uses 9 TSs in an OTU3 but
282	   only 8 in an OTU4. Examples of the number of TSs used for various
283	   cases are provided below (Referring to Table 7-9 of [G709-2012]):

285	   -  ODU0 into ODU1, ODU2, ODU3 or ODU4 multiplexing with 1,25Gbps TS
286	      granularity
287	      o  ODU0 occupies 1 of the 2, 8, 32 or 80 TSs for ODU1, ODU2, ODU3
288	         or ODU4

290	   -  ODU1 into ODU2, ODU3 or ODU4 multiplexing with 1,25Gbps TS
291	      granularity
292	      o  ODU1 occupies 2 of the 8, 32 or 80 TSs for ODU2, ODU3 or ODU4

294	   -  ODU1 into ODU2, ODU3 multiplexing with 2.5Gbps TS granularity
295	      o  ODU1 occupies 1 of the 4 or 16 TSs for ODU2 or ODU3

297	   -  ODU2 into ODU3 or ODU4 multiplexing with 1.25Gbps TS granularity
298	      o  ODU2 occupies 8 of the 32 or 80 TSs for ODU3 or ODU4

300	   -  ODU2 into ODU3 multiplexing with 2.5Gbps TS granularity
301	      o  ODU2 occupies 4 of the 16 TSs for ODU3

303	   -  ODU3 into ODU4 multiplexing with 1.25Gbps TS granularity
304	      o  ODU3 occupies 31 of the 80 TSs for ODU4

306	   -  ODUflex into ODU2, ODU3 or ODU4 multiplexing with 1.25Gbps TS
307	      granularity
308	      o  ODUflex occupies n of the 8, 32 or 80 TSs for ODU2, ODU3 or
309	         ODU4 (n <= Total TS number of ODUk)

311	   -  ODU2e into ODU3 or ODU4 multiplexing with 1.25Gbps TS granularity
312	      o  ODU2e occupies 9 of the 32 TSs for ODU3 or 8 of the 80 TSs for
313	         ODU4

315	   In general the mapping of an ODUj (including ODUflex) into a specific
316	   OTUk TS is determined locally, and it can also be explicitly
317	   controlled by a specific entity (e.g., head end, Network Management
318	   System (NMS)) through Explicit Label Control [RFC3473].

320	3.1.2.1. Structure of MSI information

322	   When multiplexing an ODUj into a HO ODUk (k>j), G.709 specifies the
323	   information that has to be transported in-band in order to allow for
324	   correct demultiplexing. This information, known as MSI, is
325	   transported in the OPUk overhead and is local to each link. In case
326	   of bidirectional paths the association between TPN and TS must be the
327	   same in both directions.

329	   The MSI information is organized as a set of entries, with one entry
330	   for each HO ODUj TS. The information carried by each entry is:

332	   -  Payload Type:  the type of the transported payload.

334	   -  TPN:  the port number of the ODUj transported by the HO ODUk. The
335	      TPN is the same for all the TSs assigned to the transport of the
336	      same ODUj instance.

338	   For example, an ODU2 carried by a HO ODU3 is described by 4 entries
339	   in the OPU3 overhead when the TS granularity is 2.5Gbps, and by 8
340	   entries when the TS granularity is 1.25Gbps.

342	   On each node and on every link, two MSI values have to be provisioned
343	   (Referring to [G798-V4]):

345	   -  The Transmitted MSI (TxMSI) information inserted in OPU (e.g.,
346	      OPU3) overhead by the source of the HO ODUk trail.

348	   -  The expected MSI (ExMSI) information that is used to check the
349	      accepted MSI (AcMSI) information. The AcMSI information is the MSI
350	      valued received in-band, after a three-frame integration.

352	   As described in [G798-V4], the sink of the HO ODU trail checks the
353	   complete content of the AcMSI information against the ExMSI. If the
354	   AcMSI is different from the ExMSI, then the traffic is dropped and a
355	   payload mismatch alarm is generated.

357	   Provisioning of TPN can be performed either by network management
358	   system or control plane. In the last case, control plane is also
359	   responsible for negotiating the provisioned values on a link by link
360	   base.

362	4. Connection management in OTN

364	   OTN-based connection management is concerned with controlling the
365	   connectivity of ODU paths and OCh. This document focuses on the
366	   connection management of ODU paths. The management of OCh paths is
367	   described in [RFC6163].

369	   While [G872-2001] considered the ODU as a set of layers in the same
370	   way as SDH has been modeled, recent ITU-T OTN architecture progress
371	   [G872-2012] includes an agreement to model the ODU as a single layer
372	   network with the bit rate as a parameter of links and connections.
373	   This allows the links and nodes to be viewed in a single topology as
374	   a common set of resources that are available to provide ODUj
375	   connections independent of the value of j. Note that when the bit
376	   rate of ODUj is less than the server bit rate, ODUj connections are
377	   supported by HO ODU (which has a one-to-one relationship with the
378	   OTU).

380	   From an ITU-T perspective, the ODU connection topology is represented
381	   by that of the OTU link layer, which has the same topology as that of
382	   the OCh layer (independent of whether the OTU supports HO ODU, where
383	   multiplexing is utilized, or LO ODU in the case of direct mapping).
384	   Thus, the OTU and OCh layers should be visible in a single
385	   topological representation of the network, and from a logical
386	   perspective, the OTU and OCh may be considered as the same logical,
387	   switchable entity.

389	   Note that the OTU link layer topology may be provided via various
390	   infrastructure alternatives, including point-to-point optical
391	   connections, optical connections fully in the optical domain and
392	   optical connections involving hybrid sub-lambda/lambda nodes
393	   involving 3R, etc, see [RFC6163] for additional information.

395	4.1. Connection management of the ODU

397	   LO ODUj can be either mapped into the OTUk signal (j = k), or
398	   multiplexed with other LO ODUjs into an OTUk (j < k), and the OTUk is
399	   mapped into an OCh.

401	   From the perspective of control plane, there are two kinds of network
402	   topology to be considered.

404	   (1) ODU layer

406	   In this case, the ODU links are presented between adjacent OTN nodes,
407	   as illustrated in Figure 2. In this layer there are ODU links with a
408	   variety of TSs available, and nodes that are Optical Digital Cross
409	   Connects (ODXCs). Lo ODU connections can be setup based on the
410	   network topology.

412	                  Link #5       +--+---+--+        Link #4
413	     +--------------------------|         |--------------------------+
414	     |                          |  ODXC   |                          |
415	     |                          +---------+                          |
416	     |                             Node E                            |
417	     |                                                               |
418	   +-++---+--+        +--+---+--+        +--+---+--+        +--+---+-++
419	   |         |Link #1 |         |Link #2 |         |Link #3 |         |
420	   |         |--------|         |--------|         |--------|         |
421	   |  ODXC   |        |  ODXC   |        |  ODXC   |        |  ODXC   |
422	   +---------+        +---------+        +---------+        +---------+
423	      Node A             Node B              Node C            Node D

425	        Figure 2 - Example Topology for LO ODU connection management

427	   If an ODUj connection is requested between Node C and Node E
428	   routing/path computation must select a path that has the required
429	   number of TS available and that offers the lowest cost.  Signaling is
430	   then invoked to set up the path and to provide the information (e.g.,
431	   selected TSs) required by each transit node to allow the
432	   configuration of the ODUj to OTUk mapping (j = k) or multiplexing (j
433	   < k), and demapping (j = k) or demultiplexing (j < k).

435	   (2) ODU layer with OCh switching capability

437	   In this case, the OTN nodes interconnect with wavelength switched
438	   node (e.g., Reconfiguration Optical Add/Drop Multiplexer (ROADM),
439	   Optical Cross-Connect (OXC)) that are capable of OCh switching, which
440	   is illustrated in Figure 3 and Figure 4. There are ODU layer and OCh
441	   layer, so it is simply a Multi-Layer Networks (MLN) (see [RFC6001]).

443	   OCh connections may be created on demand, which is described in
444	   section 5.1.

446	   In this case, an operator may choose to allow the underlined OCh
447	   layer to be visible to the ODU routing/path computation process in
448	   which case the topology would be as shown in Figure 4. In Figure 3
449	   below, instead, a cloud representing OCh capable switching nodes is
450	   represented. In Figure 3, the operator choice is to hide the real OCh
451	   layer network topology.

453	                                Node E
454	         Link #5              +--------+       Link #4
455	     +------------------------|        |------------------------+
456	     |                          ------                          |
457	     |                       //        \\                       |
458	     |                      ||          ||                      |
459	     |                      | OCh domain |                      |
460	   +-+-----+        +------ ||          || ------+        +-----+-+
461	   |       |        |        \\        //        |        |       |
462	   |       |Link #1 |          --------          |Link #3 |       |
463	   |       +--------+         |        |         +--------+       +
464	   | ODXC  |        |  ODXC   +--------+  ODXC   |        | ODXC  |
465	   +-------+        +---------+Link #2 +---------+        +-------+
466	     Node A            Node B             Node C            Node D

468	      Figure 3 - OCh Hidden Topology for LO ODU connection management

470	           Link #5            +---------+            Link #4
471	     +------------------------|         |-----------------------+
472	     |                   +----| ODXC    |----+                  |
473	     |                 +-++   +---------+   ++-+                |
474	     |         Node f  |  |     Node E      |  |  Node g        |
475	     |                 +-++                 ++-+                |
476	     |                   |       +--+        |                  |
477	   +-+-----+        +----+----+--|  |--+-----+---+        +-----+-+
478	   |       |Link #1 |         |  +--+  |         |Link #3 |       |
479	   |       +--------+         | Node h |         +--------+       |
480	   | ODXC  |        | ODXC    +--------+ ODXC    |        | ODXC  |
481	   +-------+        +---------+ Link #2+---------+        +-------+
482	     Node A            Node B            Node C             Node D

484	     Figure 4 - OCh Visible Topology for LO ODUj connection management

486	   In Figure 4, the cloud of previous figure is substitute by the real
487	   topology. The nodes f, g, h are nodes with OCh switching capability.

489	   In the examples (i.e., Figure 3 and Figure 4), we have considered the
490	   case in which LO ODUj connections are supported by OCh connection,
491	   and the case in which the supporting underlying connection can be
492	   also made by a combination of HO ODU/OCh connections.

494	   In this case, the ODU routing/path selection process will request an
495	   HO ODU/OCh connection between node C and node E from the OCh domain.
496	   The connection will appear at ODU level as a Forwarding Adjacency,
497	   which will be used to create the ODU connection.

499	5. GMPLS/PCE Implications

501	   The purpose of this section is to provide a set of requirements to be
502	   evaluated for extensions of the current GMPLS protocol suite and the
503	   PCE applications and protocols to encompass OTN enhancements and
504	   connection management.

506	5.1. Implications for Label Switch Path (LSP) Hierarchy

508	   The path computation for ODU connection request is based on the
509	   topology of ODU layer.

511	   The OTN path computation can be divided into two layers. One layer is
512	   OCh/OTUk, the other is ODUj. [RFC4206] and [RFC6107] define the
513	   mechanisms to accomplish creating the hierarchy of LSPs. The LSP
514	   management of multiple layers in OTN can follow the procedures
515	   defined in [RFC4206], [RFC6001] and [RFC6107], etc.

517	   As discussed in section 4, the route path computation for OCh is in
518	   the scope of Wavelength Switched Optical Network (WSON) [RFC6163].
519	   Therefore, this document only considers ODU layer for ODU connection
520	   request.

522	   LSP hierarchy can also be applied within the ODU layers. One of the
523	   typical scenarios for ODU layer hierarchy is to maintain
524	   compatibility with introducing new [G709-2012] services (e.g., ODU0,
525	   ODUflex) into a legacy network configuration (i.e., the legacy OTN
526	   referenced by [RFC4328]). In this scenario, it may be needed to
527	   consider introducing hierarchical multiplexing capability in specific
528	   network transition scenarios. One method for enabling multiplexing
529	   hierarchy is by introducing dedicated boards in a few specific places
530	   in the network and tunneling these new services through the legacy
531	   containers (ODU1, ODU2, ODU3), thus postponing the need to upgrade
532	   every network element to [G709-2012] capabilities.

534	   In such case, one ODUj connection can be nested into another ODUk
535	   (j<k) connection, which forms the LSP hierarchy in ODU layer. The
536	   creation of the outer ODUk connection can be triggered via network
537	   planning, or by the signaling of the inner ODUj connection. For the
538	   former case, the outer ODUk connection can be created in advance
539	   based on network planning. For the latter case, the multi-layer
540	   network signaling described in [RFC4206], [RFC6107] and [RFC6001]
541	   (including related modifications, if needed) are relevant to create
542	   the ODU connections with multiplexing hierarchy. In both cases, the
543	   outer ODUk connection is advertised as a Forwarding Adjacency (FA).

545	5.2. Implications for GMPLS Signaling

547	   The signaling function and RSVP-TE extensions are described in
548	   [RFC3471] and [RFC3473]. For OTN-specific control, [RFC4328] defines
549	   signaling extensions to support control for the legacy G.709 Optical
550	   Transport Networks.

552	   As described in Section 3, [G709-2012] introduced some new features
553	   that include the ODU0, ODU2e, ODU4 and ODUflex containers. The
554	   mechanisms defined in [RFC4328] do not support such new OTN features,
555	   and protocol extensions will be necessary to allow them to be
556	   controlled by a GMPLS control plane.

558	   [RFC4328] defines the LSP Encoding Type, the Switching Type and the
559	   Generalized Protocol Identifier (Generalized-PID) constituting the
560	   common part of the Generalized Label Request. The G.709 Traffic
561	   Parameters are also defined in [RFC4328]. The following signaling
562	   aspects should be considered additionally since [RFC4328] was
563	   published:

565	   -  Support for specifying the new signal types and the related
566	      traffic information

568	      The traffic parameters should be extended in signaling message to
569	      support the new ODUj including:

571	         -  ODU0
572	         -  ODU2e
573	         -  ODU4
574	         -  ODUflex

576	      For ODUflex signal type, its bit rate must be carried additionally
577	      in the Traffic Parameter to setup an ODUflex connection.

579	      For other ODU signal types, their bit rates and tolerances are
580	      fixed and can be deduced from the signal types.

582	   -  Support for LSP setup using different TS granularity

584	      The signaling protocol should be able to identify the TS
585	      granularity (i.e., the 2.5Gbps TS granularity and the new 1.25Gbps
586	      TS granularity) to be used for establishing an Hierarchical LSP
587	      which will be used to carry service LSP(s) requiring specific TS
588	      granularity.

590	   -  Support for LSP setup of new ODUk/ODUflex containers with related
591	      mapping and multiplexing capabilities

593	      A new label format must be defined to carry the exact TSs
594	      allocation information related to the extended mapping and
595	      multiplexing hierarchy (For example, ODU0 into ODU2 multiplexing
596	      (with 1.25Gbps TS granularity)), in order to set up the ODU
597	      connection.

599	   -  Support for TPN allocation and negotiation

601	      TPN needs to be configured as part of the MSI information (See
602	      more information in Section 3.1.2.1). A signaling mechanism must
603	      be identified to carry TPN information if control plane is used to
604	      configure MSI information.

606	   -  Support for ODU Virtual Concatenation (VCAT) and Link Capacity
607	      Adjustment Scheme (LCAS)

609	      GMPLS signaling should support the creation of Virtual
610	      Concatenation of ODUk signal with k=1, 2, 3. The signaling should
611	      also support the control of dynamic capacity changing of a VCAT
612	      container using LCAS ([G7042]). [RFC6344] has a clear description
613	      of VCAT and LCAS control in SONET/SDH and OTN networks.

615	   -  Support for Control of Hitless Adjustment of ODUflex (GFP)

617	      [G7044] has been created in ITU-T to specify Hitless Adjustment of
618	      ODUflex (GFP) (HAO) that is used to increase or decrease the
619	      bandwidth of an ODUflex (GFP) that is transported in an OTN
620	      network.

622	      The procedure of ODUflex (GFP) adjustment requires the
623	      participation of every node along the path. Therefore, it is
624	      recommended to use the control plane signaling to initiate the
625	      adjustment procedure in order to avoid the manual configuration at
626	      each node along the path.

628	      From the perspective of control plane, the control of ODUflex
629	      resizing is similar to control of bandwidth increasing and
630	      decreasing described in [RFC3209]. Therefore, the Shared Explicit
631	      (SE) style can be used for control of HAO.

633	   All the extensions above should consider the extensibility to match
634	   future evolvement of OTN.

636	5.3. Implications for GMPLS Routing

638	   The path computation process needs to select a suitable route for an
639	   ODUj connection request. In order to perform the path computation, it
640	   needs to evaluate the available bandwidth on each candidate link.
641	   The routing protocol should be extended to convey sufficient
642	   information to represent ODU Traffic Engineering (TE) topology.

644	   Interface Switching Capability Descriptors defined in [RFC4202]
645	   present a new constraint for LSP path computation. [RFC4203] defines
646	   the switching capability and related Maximum LSP Bandwidth and the
647	   Switching Capability specific information. When the Switching
648	   Capability field is TDM the Switching Capability Specific Information
649	   field includes Minimum LSP Bandwidth, an indication whether the
650	   interface supports Standard or Arbitrary SONET/SDH, and padding.
651	   Hence a new Switching Capability value needs to be defined for [G709-
652	   2012] ODU switching in order to allow the definition of a new
653	   Switching Capability Specific Information field definition. The
654	   following requirements should be considered:

656	   -  Support for carrying the link multiplexing capability

658	       As discussed in section 3.1.2, many different types of ODUj can
659	       be multiplexed into the same OTUk. For example, both ODU0 and
660	       ODU1 may be multiplexed into ODU2. An OTU link may support one or
661	       more types of ODUj signals. The routing protocol should be
662	       capable of carrying this multiplexing capability.

664	   -  Support any ODU and ODUflex

666	       The bit rate (i.e., bandwidth) of each TS is dependent on the TS
667	       granularity and the signal type of the link. For example, the
668	       bandwidth of a 1.25G TS in an OTU2 is about 1.249409620Gbps,
669	       while the bandwidth of a 1.25G TS in an OTU3 is about
670	       1.254703729Gbps.

672	       One LO ODU may need different number of TSs when multiplexed into
673	       different HO ODUs. For example, for ODU2e, 9 TSs are needed when
674	       multiplexed into an ODU3, while only 8 TSs are needed when
675	       multiplexed into an ODU4. For ODUflex, the total number of TSs to
676	       be reserved in a HO ODU equals the maximum of [bandwidth of
677	       ODUflex / bandwidth of TS of the HO ODU].

679	       Therefore, the routing protocol should be capable of carrying the
680	       necessary link bandwidth information for performing accurate
681	       route computation for any of the fixed rate ODUs as well as
682	       ODUflex.

684	   -  Support for differentiating between terminating and switching
685	      capability

687	       Due to internal constraints and/or limitations, the type of
688	       signal being advertised by an interface could be restricted to
689	       switched (i.e. forwarded to switching matrix without
690	       multiplexing/demultiplexing actions), restricted to terminated
691	       (demuxed) or both of them. The capability advertised by an
692	       interface needs further distinction in order to separate
693	       termination and switching capabilities.

695	       Therefore, to allow the required flexibility, the routing
696	       protocol should clearly distinguish the terminating and switching
697	       capability.

699	   -  Support for Tributary Slot Granularity advertisement

701	       [G709-2012] defines two types of TS but each link can only
702	       support a single type at a given time. In order to perform a
703	       correct path computation (i.e. the LSP end points have matching
704	       Tributary Slot Granularity values) the Tributary Slot Granularity
705	       needs to be advertised.

707	   -  Support different priorities for resource reservation

709	       How many priorities levels should be supported depends on the
710	       operator's policy. Therefore, the routing protocol should be
711	       capable of supporting up to 8 priority levels as defined in
712	       [RFC4202].

714	   -  Support link bundling

716	       As described in [RFC4201], link bundling can improve routing
717	       scalability by reducing the amount of TE links that has to be
718	       handled by routing protocol. The routing protocol should be
719	       capable of supporting bundling multiple OTU links, at the same
720	       line rate and muxing hierarchy, between a pair of nodes as a TE
721	       link. Note that link bundling is optional and is implementation
722	       dependent.

724	   -  Support for Control of Hitless Adjustment of ODUflex (GFP)

726	       The control plane should support hitless adjustment of ODUflex,
727	       so the routing protocol should be capable of differentiating
728	       whether an ODU link can support hitless adjustment of ODUflex
729	       (GFP) or not, and how much resource can be used for resizing.
730	       This can be achieved by introducing a new signal type
731	       "ODUflex(GFP-F), resizable" that implies the support for hitless
732	       adjustment of ODUflex (GFP) by that link.

734	   As mentioned in Section 5.1, one method of enabling multiplexing
735	   hierarchy is via usage of dedicated boards to allow tunneling of new
736	   services through legacy ODU1, ODU2, ODU3 containers. Such dedicated
737	   boards may have some constraints with respect to switching matrix
738	   access; detection and representation of such constraints is for
739	   further study.

741	5.4. Implications for Link Management Protocol

743	   As discussed in section 5.3, Path computation needs to know the
744	   interface switching capability of links. The switching capability of
745	   two ends of the link may be different, so the link capability of two
746	   ends should be correlated.

748	   LMP [RFC4204] provides a control plane protocol for exchanging and
749	   correlating link capabilities.

751	   Note that LO ODU type information can be, in principle, discovered by
752	   routing. Since in certain cases, routing is not present (e.g. User-
753	   Network Interface (UNI) case) we need to extend link management
754	   protocol capabilities to cover this aspect. In case of routing
755	   presence, the discovery via LMP could also be optional.

757	   -  Correlating the granularity of the TS

759	       As discussed in section 3.1.2, the two ends of a link may support
760	       different TS granularity. In order to allow interconnection the
761	       node with 1.25Gbps granularity should fall back to 2.5Gbps
762	       granularity.

764	       Therefore, it is necessary for the two ends of a link to
765	       correlate the granularity of the TS. This ensures the correct use
766	       and of the TE link.

768	   -  Correlating the supported LO ODU signal types and multiplexing
769	      hierarchy capability

771	       Many new ODU signal types have been introduced in [G709-2012],
772	       such as ODU0, ODU4, ODU2e and ODUflex. It is possible that
773	       equipment does not support all the LO ODU signal types introduced
774	       by those new standards or drafts. Furthermore, since multiplexing
775	       hierarchy was not allowed by the legacy OTN referenced by
776	       [RFC4328], it is possible that only one end of an ODU link can
777	       support multiplexing hierarchy capability, or the two ends of the
778	       link support different multiplexing hierarchy capabilities (e.g.,
779	       one end of the link supports ODU0 into ODU1 into ODU3
780	       multiplexing while the other end supports ODU0 into ODU2 into
781	       ODU3 multiplexing).

783	       For the control and management consideration, it is necessary for
784	       the two ends of an HO ODU link to correlate which types of LO ODU
785	       can be supported and what multiplexing hierarchy capabilities can
786	       be provided by the other end.

788	5.5. Implications for Control Plane Backward Compatibility

790	   With the introduction of [G709-2012], there may be OTN networks
791	   composed of a mixture of nodes, some of which support the legacy OTN
792	   and run control plane protocols defined in [RFC4328], while others
793	   support [G709-2012] and new OTN control plane characterized in this
794	   document. Note that a third case, for the sake of completeness,
795	   consists on nodes supporting the legacy OTN referenced by [RFC4328]
796	   with a new OTN control plane, but such nodes can be considered as new
797	   nodes with limited capabilities.

799	   This section discusses the compatibility of nodes implementing the
800	   control plane procedures defined [RFC4328], in support of the legacy
801	   OTN, and the control plane procedures defined to support [G709-2012],
802	   as outlined by this document.

804	   Compatibility needs to be considered only when controlling ODU1 or
805	   ODU2 or ODU3 connection, because the legacy OTN only support these
806	   three ODU signal types. In such cases, there are several possible
807	   options including:

809	   -  A node supporting [G709-2012] could support only the [G709-2012]
810	      related control plane procedures, in which case both types of
811	      nodes would be unable to jointly control an LSP for an ODU type
812	      that both nodes support in the data plane. Note that this case is
813	      supported by the procedures defined in [RFC3473] as a different
814	      Switching Capability/Type value is used for the different control
815	      plane versions.

817	   -  A node supporting [G709-2012] could support both the [G709-2012]
818	      related control plane and the control plane defined in [RFC4328].

820	      o  Such a node could identify which set of procedure to follow
821	         when initiating an LSP based on the Switching Capability value
822	         advertised in routing.

824	      o  Such a node could follow the set of procedures based on the
825	         Switching Type received in signaling messages from an upstream
826	         node.

828	      o  Such a node, when processing a transit LSP, could select which
829	         signaling procedures to follow based on the Switching
830	         Capability value advertised in routing by the next hop node.

832	5.6. Implications for Path Computation Elements

834	   [PCE-APS] describes the requirements for GMPLS applications of PCE in
835	   order to establish GMPLS LSP. PCE needs to consider the GMPLS TE
836	   attributes appropriately once a Path Computation Client (PCC) or
837	   another PCE requests a path computation. The TE attributes which can
838	   be contained in the path calculation request message from the PCC or
839	   the PCE defined in [RFC5440] includes switching capability, encoding
840	   type, signal type, etc.

842	   As described in section 5.2.1, new signal types and new signals with
843	   variable bandwidth information need to be carried in the extended
844	   signaling message of path setup. For the same consideration, PCE
845	   Communication Protocol (PCECP) also has a desire to be extended to
846	   carry the new signal type and related variable bandwidth information
847	   when a PCC requests a path computation.

849	6. Data Plane Backward Compatibility Considerations

851	   If MI AUTOpayloadtype is activated (see [G798-V4]), a node supporting
852	   1.25Gbps TS can interwork with the other nodes that supporting
853	   2.5Gbps TS by combining Specific TSs together in data plane. The
854	   control plane must support this TS combination.

856	                                Path
857	            +----------+   ------------>    +----------+
858	            |     TS1==|===========\--------+--TS1     |
859	            |     TS2==|=========\--\-------+--TS2     |
860	            |     TS3==|=======\--\--\------+--TS3     |
861	            |     TS4==|=====\--\--\--\-----+--TS4     |
862	            |          |      \  \  \  \----+--TS5     |
863	            |          |       \  \  \------+--TS6     |
864	            |          |        \  \--------+--TS7     |
865	            |          |         \----------+--TS8     |
866	            +----------+   <------------    +----------+
867	               node A           Resv           node B

869	         Figure 5 - Interworking between 1.25Gbps TS and 2.5Gbps TS

871	   Take Figure 5 as an example. Assume that there is an ODU2 link
872	   between node A and B, where node A only supports the 2.5Gbps TS while
873	   node B supports the 1.25Gbps TS. In this case, the TS#i and TS#i+4
874	   (where i<=4) of node B are combined together. When creating an ODU1
875	   service in this ODU2 link, node B reserves the TS#i and TS#i+4 with
876	   the granularity of 1.25Gbps. But in the label sent from B to A, it is
877	   indicated that the TS#i with the granularity of 2.5Gbps is reserved.

879	   In the opposite direction, when receiving a label from node A
880	   indicating that the TS#i with the granularity of 2.5Gbps is reserved,
881	   node B will reserved the TS#i and TS#i+4 with the granularity of
882	   1.25Gbps in its data plane.

884	7. Security Considerations

886	   The use of control plane protocols for signaling, routing, and path
887	   computation opens an OTN to security threats through attacks on those
888	   protocols. Although, this is not greater than the risks presented by
889	   the existing OTN control plane as defined by [RFC4203] and [RFC4328].

891	   For further details of the specific security measures refer to the
892	   documents that define the protocols ([RFC3473], [RFC4203], [RFC5307],
893	   [RFC4204], and [RFC5440]). [RFC5920] provides an overview of security
894	   vulnerabilities and protection mechanisms for the GMPLS control
895	   plane.

897	8. IANA Considerations

899	   This document makes not requests for IANA action.

901	9. Acknowledgments

903	   We would like to thank Maarten Vissers and Lou Berger for their
904	   review and useful comments.

906	10. References

908	10.1. Normative References

910	   [RFC3209]   Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.
911	               and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
912	               Tunnels", RFC 3209, December 2001.

914	   [RFC3471]   Berger, L., Editor, "Generalized Multi-Protocol Label
915	               Switching (GMPLS) Signaling Functional Description", RFC
916	               3471, January 2003.

918	   [RFC3473]   L. Berger, Ed., "Generalized Multi-Protocol Label
919	               Switching (GMPLS) Signaling Resource ReserVation
920	               Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
921	               3473, January 2003.

923	   [RFC4201]   K. Kompella, Y. Rekhter, Ed., "Link Bundling in MPLS
924	               Traffic Engineering (TE)", RFC 4201, October 2005.

926	   [RFC4202]   K. Kompella, Y. Rekhter, Ed., "Routing Extensions in
927	               Support of Generalized Multi-Protocol Label Switching
928	               (GMPLS)", RFC 4202, October 2005.

930	   [RFC4203]   K. Kompella, Y. Rekhter, Ed., "OSPF Extensions in Support
931	               of Generalized Multi-Protocol Label Switching (GMPLS)",
932	               RFC 4203, October 2005.

934	   [RFC4204]   Lang, J., Ed., "Link Management Protocol (LMP)", RFC
935	               4204, October 2005.

937	   [RFC4206]   K. Kompella, Y. Rekhter, Ed., "Label Switched Paths (LSP)
938	               Hierarchy with Generalized Multi-Protocol Label Switching
939	               (GMPLS) Traffic Engineering (TE)", RFC 4206, October
940	               2005.

942	   [RFC4328]   D. Papadimitriou, Ed. "Generalized Multi-Protocol
943	               LabelSwitching (GMPLS) Signaling Extensions for G.709
944	               Optical Transport Networks Control", RFC 4328, Jan 2006.

946	   [RFC5307]   K. Kompella, Y. Rekhter, Ed., "IS-IS Extensions in
947	               Support of Generalized Multi-Protocol Label Switching
948	               (GMPLS)", RFC 5307, October 2008.

950	   [RFC5440]   JP. Vasseur, JL. Le Roux, Ed.," Path Computation Element
951	               (PCE) Communication Protocol (PCEP)", RFC 5440, March
952	               2009.

954	   [RFC6001]   Dimitri Papadimitriou et al, "Generalized Multi-Protocol
955	               Label Switching (GMPLS) Protocol Extensions for Multi-
956	               Layer and Multi-Region Networks (MLN/MRN)", RFC6001,
957	               February 21, 2010.

959	   [RFC6107]   K. Shiomoto, A. Farrel, "Procedures for Dynamically
960	               Signaled Hierarchical Label Switched Paths", RFC6107,
961	               February 2011.

963	   [RFC6344]   G. Bernstein et al, "Operating Virtual Concatenation
964	               (VCAT) and the Link Capacity Adjustment Scheme (LCAS)
965	               with Generalized Multi-Protocol Label Switching (GMPLS)",
966	               RFC6344, August, 2011.

968	   [G709-2012] ITU-T, "Interface for the Optical Transport Network
969	               (OTN)", G.709/Y.1331 Recommendation, February 2012.

971	10.2. Informative References

973	   [G798-V4]   ITU-T, "Characteristics of optical transport network
974	               hierarchy equipment functional blocks", G.798
975	               Recommendation, October 2010.

977	   [G7042]     ITU-T, "Link capacity adjustment scheme (LCAS) for
978	               virtual concatenated signals", G.7042/Y.1305, March 2006.

980	   [G872-2001] ITU-T, "Architecture of optical transport networks",
981	               G.872 Recommendation, November 2001.

983	   [G872-2012] ITU-T, "Architecture of optical transport networks",
984	               G.872 Recommendation, October 2012.

986	   [G7044]     ITU-T, "Hitless adjustment of ODUflex", G.7044/Y.1347,
987	               October 2011.

989	   [G7041]     ITU-T, "Generic framing procedure", G.7041/Y.1303, April
990	               2011.

992	   [RFC3945]   Mannie, E., "Generalized Multi-Protocol Label Switching
993	               (GMPLS) Architecture", RFC 3945, October 2004.

995	   [RFC4655]   Farrel, A., Vasseur, J., and J. Ash, "A Path
996	               Computation Element (PCE)-Based Architecture",
997	               RFC 4655, August 2006.

999	   [RFC6163]   Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS
1000	               and PCE Control of Wavelength Switched Optical Networks
1001	               (WSON)", RFC6163, April 2011.

1003	   [PCE-APS]   Tomohiro Otani, Kenichi Ogaki, Diego Caviglia, and Fatai
1004	               Zhang, "Requirements for GMPLS applications of PCE",
1005	               draft-ietf-pce-gmpls-aps-req, Work in Progress.

1007	   [RFC5920]   Fang, L., Ed., "Security Framework for MPLS and GMPLS
1008	               Networks", RFC5920, July 2010.

1010	11. Authors' Addresses

1012	   Fatai Zhang (editor)
1013	   Huawei Technologies
1014	   F3-5-B R&D Center, Huawei Base
1015	   Bantian, Longgang District
1016	   Shenzhen 518129 P.R.China

1018	   Phone: +86-755-28972912
1019	   Email: zhangfatai@huawei.com

1021	   Dan Li
1022	   Huawei Technologies Co., Ltd.
1023	   F3-5-B R&D Center, Huawei Base
1024	   Bantian, Longgang District
1025	   Shenzhen 518129 P.R.China
1026	   Phone: +86-755-28973237
1027	   Email: huawei.danli@huawei.com

1029	   Han Li
1030	   China Mobile Communications Corporation
1031	   53 A Xibianmennei Ave. Xuanwu District
1032	   Beijing 100053 P.R. China

1034	   Phone: +86-10-66006688
1035	   Email: lihan@chinamobile.com

1037	   Sergio Belotti
1038	   Alcatel-Lucent
1039	   Optics CTO
1040	   Via Trento 30 20059 Vimercate (Milano) Italy
1041	   +39 039 6863033

1043	   Email: sergio.belotti@alcatel-lucent.it

1045	   Daniele Ceccarelli
1046	   Ericsson
1047	   Via A. Negrone 1/A
1048	   Genova - Sestri Ponente
1049	   Italy
1050	   Email: daniele.ceccarelli@ericsson.com

1052	12. Contributors

1054	   Jianrui Han
1055	   Huawei Technologies Co., Ltd.
1056	   F3-5-B R&D Center, Huawei Base
1057	   Bantian, Longgang District
1058	   Shenzhen 518129 P.R.China

1060	   Phone: +86-755-28972913
1061	   Email: hanjianrui@huawei.com

1063	   Malcolm Betts
1064	   Huawei Technologies Co., Ltd.

1066	   Email: malcolm.betts@huawei.com
1067	   Pietro Grandi
1068	   Alcatel-Lucent
1069	   Optics CTO
1070	   Via Trento 30 20059 Vimercate (Milano) Italy
1071	   +39 039 6864930

1073	   Email: pietro_vittorio.grandi@alcatel-lucent.it

1075	   Eve Varma
1076	   Alcatel-Lucent
1077	   1A-261, 600-700 Mountain Av
1078	   PO Box 636
1079	   Murray Hill, NJ  07974-0636
1080	   USA
1081	   Email: eve.varma@alcatel-lucent.com

1083	 Intellectual Property

1085	   The IETF Trust takes no position regarding the validity or scope of
1086	   any Intellectual Property Rights or other rights that might be
1087	   claimed to pertain to the implementation or use of the technology
1088	   described in any IETF Document or the extent to which any license
1089	   under such rights might or might not be available; nor does it
1090	   represent that it has made any independent effort to identify any
1091	   such rights.

1093	   Copies of Intellectual Property disclosures made to the IETF
1094	   Secretariat and any assurances of licenses to be made available, or
1095	   the result of an attempt made to obtain a general license or
1096	   permission for the use of such proprietary rights by implementers or
1097	   users of this specification can be obtained from the IETF on-line IPR
1098	   repository at http://www.ietf.org/ipr

1100	   The IETF invites any interested party to bring to its attention any
1101	   copyrights, patents or patent applications, or other proprietary
1102	   rights that may cover technology that may be required to implement
1103	   any standard or specification contained in an IETF Document. Please
1104	   address the information to the IETF at ietf-ipr@ietf.org.

1106	   The definitive version of an IETF Document is that published by, or
1107	   under the auspices of, the IETF. Versions of IETF Documents that are
1108	   published by third parties, including those that are translated into
1109	   other languages, should not be considered to be definitive versions
1110	   of IETF Documents. The definitive version of these Legal Provisions
1111	   is that published by, or under the auspices of, the IETF. Versions of
1112	   these Legal Provisions that are published by third parties, including
1113	   those that are translated into other languages, should not be
1114	   considered to be definitive versions of these Legal Provisions.

1116	   For the avoidance of doubt, each Contributor to the IETF Standards
1117	   Process licenses each Contribution that he or she makes as part of
1118	   the IETF Standards Process to the IETF Trust pursuant to the
1119	   provisions of RFC 5378. No language to the contrary, or terms,
1120	   conditions or rights that differ from or are inconsistent with the
1121	   rights and licenses granted under RFC 5378, shall have any effect and
1122	   shall be null and void, whether published or posted by such
1123	   Contributor, or included with or in such Contribution.

1125	Disclaimer of Validity

1127	   All IETF Documents and the information contained therein are provided
1128	   on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
1129	   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
1130	   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
1131	   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
1132	   WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
1133	   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
1134	   FOR A PARTICULAR PURPOSE.

1136	Copyright Notice

1138	   Copyright (c) 2013 IETF Trust and the persons identified as the
1139	   document authors.  All rights reserved.

1141	   This document is subject to BCP 78 and the IETF Trust's Legal
1142	   Provisions Relating to IETF Documents
1143	   (http://trustee.ietf.org/license-info) in effect on the date of
1144	   publication of this document.  Please review these documents
1145	   carefully, as they describe your rights and restrictions with respect
1146	   to this document.  Code Components extracted from this document must
1147	   include Simplified BSD License text as described in Section 4.e of
1148	   the Trust Legal Provisions and are provided without warranty as
1149	   described in the Simplified BSD License.