Internet Engineering Task Force Q. Wang, Ed.
Internet-Draft ZTE
Intended status: Informational I. Hussain, Ed.
Expires: January 9, 2017 K. Pithewan
R. Valiveti
Infinera
July 8, 2016
Framework and Requirements for GMPLS-based Control of Flexible Ethernet
Network
draft-wang-ccamp-flexe-fwk-02
Abstract
Flex Ethernet (FlexE) technology, which is defined by Optical
Internetworking Forum (OIF), is a new kind of data plane technology
and can be used to provides a generic mechanism for supporting a
variety of Ethernet MAC rates that may or may not correspond to any
existing Ethernet PHY rate. This includes MAC rates that are greater
than (through bonding) and less than (through sub-rate and
channelization) the standard Ethernet PHY rates.
Based on the applications/use cases given in the Flex Ethernet
Implementation Agreement [FlexE-IA], this document defines a
framework and control plane requirements for the application of
existing GMPLS architecture and control plane protocols to the
control of flexible Ethernet network. The actual extensions to the
GMPLS protocols will be defined in companion documents.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 9, 2017.
Wang, et al. Expires January 9, 2017 [Page 1]
Internet-Draft GMPLS FlexE Framework July 2016
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Overview of FlexE Networks . . . . . . . . . . . . . . . . . 4
2.1. FlexE Terminology . . . . . . . . . . . . . . . . . . . . 4
2.2. Scenarios Supported by FlexE . . . . . . . . . . . . . . 4
2.3. FlexE Layer Model . . . . . . . . . . . . . . . . . . . . 5
2.3.1. Layer Model in FlexE Unaware Case . . . . . . . . . . 5
2.3.2. Layer Model in FlexE Terminating Case . . . . . . . . 6
2.3.3. Layer Model in FlexE Aware Case . . . . . . . . . . . 8
3. GMPLS Applicability . . . . . . . . . . . . . . . . . . . . . 9
3.1. General Considerations . . . . . . . . . . . . . . . . . 9
3.2. Consideration of FlexE LSPs . . . . . . . . . . . . . . . 9
3.3. Control-Plane Modelling of FlexE Network Elements . . . . 10
3.4. FlexE Layer Resource Allocation Considerations . . . . . 10
3.5. Neighbour Discovery and Link Property Correlation . . . . 11
3.6. Routing and Topology Dissemination . . . . . . . . . . . 11
3.7. Resizing of FlexE . . . . . . . . . . . . . . . . . . . . 12
4. Control-Plane Requirements . . . . . . . . . . . . . . . . . 12
4.1. Support for Signalling of FlexE . . . . . . . . . . . . . 12
4.2. Support for Routing of FlexE . . . . . . . . . . . . . . 12
4.3. Support for Neighbour Discovery and Link Property and
Link Correlation . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. Manageability Considerations . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
Wang, et al. Expires January 9, 2017 [Page 2]
Internet-Draft GMPLS FlexE Framework July 2016
1. Introduction
Traditionally, Ethernet MAC rates were constrained to match the rates
of the Ethernet PHY(s). OIF recently approved Flex Ethernet (FlexE)
Implementation Agreement [FlexE-IA], which can be used to provide a
generic mechanism to support a variety of Ethernet MAC rates that may
or may not correspond to any existing Ethernet PHY rate. In this
kind of network scenario, FlexE uses more than one Ethernet PHYs as
server layer and these Ethernet PHYs are bonded together as a FlexE
group to carry FlexE client signal. The general capabilities
supported by FlexE implementation includes:
Bonding of Ethernet PHYs, e.g., supporting a 200G MAC over two
bonded 100GBASE-R PHYs.
Sub-rates of Ethernet PHYs, e.g., supporting a 50G MAC over a
100GBASE-R PHY.
Channelization within a PHY or a group of bonded PHYs, e.g,
support a 150G and two 25G MACs over two bonded 100GBASE-R PHYs.
Note that hybrids are also possible, for example a sub-rate of a
group of bonded PHYs, for example, a 250G MAC over three bonded
100GBASE-R PHYs. For more use cases, you can refer to [draft-
hussain-ccamp-flexe-usecases].
In order to operate on the Ethernet PHYs, FlexE capable nodes uses a
calendar to assign slot positions on sub-calendars on each PHY of the
FlexE group for each of the FlexE clients. The calendar has a
granularity of 5G, and has a length of 20 slots per 100G Ethernet
PHYs.
Based on the FlexE Implementation Agreement [FlexE-IA], this document
defines the framework for GMPLS-based control of flexible Ethernet
network to depict the layer model of Flex Ethernet as well as a set
of associated control-plane requirements.
Note: currently, ITU-T already include this part of work, such as,
[ITU-T G.709] already include the content of mapping of FlexE Client
signals into OPUflex using a new mapping method, and mapping of FlexE
Aware signals into OPUflex. Also [ITU-T G.872] is going to include a
description of FlexE, such as the layer model in different cases.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Wang, et al. Expires January 9, 2017 [Page 3]
Internet-Draft GMPLS FlexE Framework July 2016
2. Overview of FlexE Networks
2.1. FlexE Terminology
This section describes the definitions of the terms used in FlexE
networks. More details about these terms can be found in OIF Flex
Ethernet (FlexE) Implementation Agreement [FlexE-IA].
FlexE group: the FlexE Group refers to a group of from 1 to n
bonded Ethernet PHYs. This version of the Implementation
Agreement supports FlexE groups composed of one or more bonded
100GBASE-R PHYs.
FlexE Client: a FlexE Client is an Ethernet flow based on a MAC
data rate that may or may not correspond to any Ethernet PHY rate.
The FlexE client MAC rates supported by this implementation
agreement are 10, 40, and m * 25 Gb/s.
FlexE Shim: the FlexE Shim is the layer that maps or demaps the
FlexE clients carried over a FlexE group. The FlexE mux refers to
the transmit direction which maps the FlexE clients over the FlexE
group. The FlexE demux refers to the receive direction which
demaps the FlexE clients from the FlexE group.
2.2. Scenarios Supported by FlexE
According to the FlexE Implementation Agreement [FlexE-IA], FlexE can
support a variety of cases. A non-exhaustive list includes:
One case of router to transport connection is where the transport
network is unaware of FlexE. This may be used with legacy
transport equipment that provides PCS-codeword transparent
transport of 100GbE, but provides no special support for FlexE.
In this case, all PHYs of the FlexE group are carried
independently, but over the same fiber route, over the transport
network.
Another case of router to transport connection is where the
transport network equipment terminates the FlexE group. In the
FlexE terminating case, FlexE group is terminated before crossing
the transport network and FlexE client is extracted from the FlexE
signal and then carried over the transport network.
The final router to transport example described is one where the
transport network is aware that it is carrying FlexE PHYs (as
opposed to 100GbE), but the FlexE group is not terminated on the
transport equipment. Transport network equipment may "crunch" the
PHY of the FlexE group by allowing bits or bytes to be discarded
Wang, et al. Expires January 9, 2017 [Page 4]
Internet-Draft GMPLS FlexE Framework July 2016
from the unavailable calendar slots at the transport network
ingress and these bits or bytes re-inserted with fixed values at
the transport network egress. This may be used to support cases
where the Ethernet PHY rate is be greater than the wavelength
rate, the wavelength rate is not an integral multiple of the PHY
rate, or there is a reason (for example, wavelengths terminated on
different transponder line cards) that it is not possible to
terminate the FlexE group in the transport equipment. This kind
of equipment is a kind of special transport equipment which can
support partial-rate transport.
2.3. FlexE Layer Model
Based on the cases addressed in section 2.2, FlexE has different
kinds of mapping hierarchy accordingly. This section gives some
description of FlexE layer model in different cases. Figure 1
depicts a FlexE layered network scenario. In this network, B and E
are FlexE capable nodes, C and D are OTN ODUflex/ODU4 capable nodes.
Node B, C are mainly used to encapsulate the client layer signal into
the server layer, while node D, E are mainly used to extract the
client layer signal from the server layer signal.
As defined in FlexE Implementation Agreement, a FlexE client may be
generated internally within a system, received from an Ethernet PHY
or from another FlexE shim. In this network scenario, we suppose the
FlexE client is generated in router B.
Feature of cases can be found in section 3.2.
In all the following cases, we suppose FlexE client at node B has a
path setup request from source B to destination E.
+---+ +---+
| B | | E |
+---+ +---+
\ /
\ /
+---+ +---+
| C |----------| D |
+---+ +---+
Figure 1: FlexE Layer Network
2.3.1. Layer Model in FlexE Unaware Case
In this case which is depicted in Figure 2, there exist four network
layers. FlexE client layer represents an end-to-end connection,
which is from the source B to destination E. When the FlexE client
Wang, et al. Expires January 9, 2017 [Page 5]
Internet-Draft GMPLS FlexE Framework July 2016
signal is generated inside node B, the FlexE client signal is first
mapped into the slots of FlexE, then the FlexE signal is carried by
Ethernet PHYs towards the destination E. When the Ethernet PHYs
arrive at node C, each PHY will be mapped into a separate ODU4
connection and then forwarded across the OTN network towards the ODU
layer connection destination D.
Note: in this case, more than one FlexE clients can be carried by
FlexE layer.
Four layers exist in this case, and the mapping hierarchy between
node C and node D can be seen in Figure 3.
Ethernet Client Connections
|-----------------------------------------|
FlexE Connection
|---------------------------------------|
+---+ +---+
| B | PHY Connections | E |
+---+|--------------------------------|+---+
\ /
\ /
+---+ ODU4 Connections +---+
| C |--------------------| D |
+---+ +---+
Figure 2: FlexE Unaware Layer Network
+------------------+
| Ethernet Client |
+------------------+
| FlexE |
+------------------+
| PHY | PHY |
+------------------+
| ODU4 | ODU4 |
+------------------+
Figure 3: FlexE Unaware Layer Hierarchy
2.3.2. Layer Model in FlexE Terminating Case
In this case, FlexE client layer represents an end-to-end connection,
which is from the source B to destination E. When the FlexE client
signal is generated inside node B,, the Ethernet signal is first
mapped into the slots of FlexE, then the FlexE signal is carried by
Ethernet PHYs towards the destination C. When the FlexE signal
arrives at node C, node C first extracts the FlexE client signal,
Wang, et al. Expires January 9, 2017 [Page 6]
Internet-Draft GMPLS FlexE Framework July 2016
then maps the Ethernet client signal into ODU signal and forwards
across the OTN network towards destination node D. Node D will first
extract the FlexE client signal from the ODU signal, then map the
Ethernet client signal into FlexE signal, which will then be carried
by Ethernet PHYs towards destination node E.
Two segments of FlexE connection exist in this case. one is from node
B to node C, and the other is from node D to node E.
Ethernet Client Connection
|----------------------------------------|
+---+ +---+
| B | | E |
+---+ +---+
PHY Connections\FlexE Connection /
\ /
+---+ ODU Connection +---+
| C |--------------------| D |
+---+ +---+
Figure 4: FlexE Terminating Layer Network
Two kinds of mapping hierarchy exist. For the signal transferred on
the links between B and C, D and E, the mapping hierarchy is depicted
in Figure 5. For the signal transferred on the links between C and
D, the mapping hierarchy is depicted in Figure 6.
+------------------+
| Ethernet Client |
+------------------+
| FlexE |
+------------------+
| PHY | PHY |
+------------------+
Figure 5: Mapping Hierarchy of FlexE
+------------------+
| Ethernet Client |
+------------------+
| ODU |
+------------------+
Figure 6: Mapping Hierarchy on OTN Link
Wang, et al. Expires January 9, 2017 [Page 7]
Internet-Draft GMPLS FlexE Framework July 2016
2.3.3. Layer Model in FlexE Aware Case
FlexE client layer represents an end-to-end connection, which is from
the source B to destination E. When the FlexE client signal is
generated inside node B,, the Ethernet signal is first mapped into
the slots of FlexE, then the FlexE signal is carried by Ethernet PHYs
towards the destination E. When the FlexE signal arrives at node C,
node C will first discards unavailable slots, then transfers the
remaining FlexE slots to ODU Connection. According to the
description in [ITU-T G.709], these FlexE slots are carried across
the OTN network via other ODUflex signals carried in other
ODUCn/OTUCn/OTSiA signals.
In this scenario, Ethernet PHYs connection exist between node B and
node C, node D and node E.
Ethernet Client Connection
|-----------------------------------------|
FlexE Connection
|---------------------------------------|
+---+ +---+
| B | | E |
+---+ +---+
PHY Connections\ /
\ /
+---+ ODUFlex Connection +---+
| C |--------------------| D |
+---+ +---+
Figure 7: FlexE Aware Layer Network
Two kinds of mapping hierarchy exist. For the signal transferred on
the links between B and C, D and E, the mapping hierarchy can be seen
in Figure 8. For the signal transferred on the links between C and
D, the mapping hierarchy can be seen in Figure 9.
+------------------+
| Ethernet Client |
+------------------+
| FlexE |
+------------------+
| PHY | PHY |
+------------------+
Figure 8: Mapping Hierarchy of FlexE
Wang, et al. Expires January 9, 2017 [Page 8]
Internet-Draft GMPLS FlexE Framework July 2016
+------------------+
| Ethernet Client |
+------------------+
| FlexE |
+------------------+
| ODUFlex |
+------------------+
Figure 9: Mapping Hierarchy on OTN Link
3. GMPLS Applicability
The goal of this section is to provide an insight into the
application of GMPLS as a control mechanism in FlexE networks.
Specific control-plane requirements for the support of FlexE networks
are covered in Section 4. This section aims to describe the
modelling of controlling the FlexE shim layer specific attributes in
different network scenario based on the capability of FlexE described
in OIF Flex Ethernet (FlexE) Implementation Agreement. [FlexE-IA]
3.1. General Considerations
The GMPLS control of the FlexE layer deals with the establishment of
FlexE connections that are transferred in FlexE capable nodes. GMPLS
labels are used to locally represent the FlexE connections and its
associated slots assignment information for client.
3.2. Consideration of FlexE LSPs
The FlexE LSP is a control-plane representation of a FlexE Connection
and MUST be carried by Ethernet PHYs LSP or ODU LSP in the network.
Figure 4 depicts a scenario that the FlexE LSP is carried over
Ethernet PHYs LSP between node B and node C, node D and node E. When
the Ethernet client signal arrives at node B, node B first check if
there are enough Ethernet PHYs available for setting up FlexE LSP.
If no, node B will first set up Ethernet PHYs LSP from node B to node
C, and then set up the FlexE LSP over the Ethernet PHYs LSP. This
process involves two signalling procedures, one is to set up Ethernet
PHYs, and the other is used to set up FlexE LSP over the Ethernet
PHYs. The set-up signalling of FlexE LSP includes the allocation of
resource for Ethernet client.
Figure 7 depicts a scenario that the FlexE LSP is carried over ODU
LSP between node C and node D. This scenario is different, and is
used to support cases where the Ethernet PHY rate is be greater than
the wavelength rate, the wavelength rate is not an integral multiple
of the PHY rate. Node C and node D support the partial-rate ability.
Wang, et al. Expires January 9, 2017 [Page 9]
Internet-Draft GMPLS FlexE Framework July 2016
When the FlexE LSP over Ethernet PHYs arrives at node C, node C first
check if there is enough resource for carrying the FlexE LSP signal
across the transport network. If no, node C will check if there is
enough resource for carrying FlexE LSP signal after discarding the
unavailable slots. If yes, node C will first set up the ODUFlex LSP
to node D, and then continue the signalling process of FlexE LSP
across the transport network.
3.3. Control-Plane Modelling of FlexE Network Elements
FlexE is a new kinds of transport technology, which has many new
constraints. These constraints are listed below:
Unavailable slots: this is different from "unused" slot, in that
it is known, due to transport network constraints, that not all of
the calendar slots generated from the FlexE mux will reach the
FlexE demux and therefore no FlexE client should be assigned to
those slots. As defined in the Flex Ethernet Implementation
Agreement, unavailable slots are always at the end of the sub-
calendar configuration for the respective PHY.
Unused slots: unused slots can be allocated to Ethernet client as
available resource.
Partial-rate capability: the partial-rate capability is usually
supported by an OTN access equipment. If an equipment supports
partial-rate, it means this equipment has the capability of
discarding unavailable slots and transfers the left slots across
OTN transport network.
Slot granularity: currently, only one kinds of 5G slot granularity
is defined in OIF Flex Ethernet (FlexE) Implementation Agreement.
3.4. FlexE Layer Resource Allocation Considerations
FlexE LSP transfers based on the slot information, so it SHOULD be
able to expose the unused slot resource information towards the
client layer. Besides the slot information, there are also some
other attributes that need to be specified when allocating resource.
In GMPLS-controlled system, these information should be taken into
consideration as a label when forwarding.
FlexE group number: a bunch of Ethernet PHYs can be bounded
together and used as a whole as one FlexE LSP. FlexE LSPs between
the same source and destination equipment SHOULD NOT have the same
FlexE group number. Source equipment and destination equipment
SHOULD be aware of the existing of different FlexE groups and
which Ethernet PHYs are in which FlexE group.
Wang, et al. Expires January 9, 2017 [Page 10]
Internet-Draft GMPLS FlexE Framework July 2016
PHY Number: it's a dynamic and logical number that is assigned
through control plane or management plane, which is unique within
the context of (source, destination), and has a one-to-one
correlation with physical port. This information will also be
carried in the FlexE overhead. Source equipment and destination
equipment SHOULD negotiate a value for every Ethernet PHYs within
one FlexE group.
Slot Assignment information: the FlexE LSP transfers based on the
slot positions, so the equipment SHOULD be able to tell which slot
is assigned to which client.
Partial-rate: during the process of resource allocation, where the
partial-rate would happen should be indicated.
Granularity: currently, only one kinds of 5G slot granularity is
defined in OIF Flex Ethernet (FlexE) Implementation Agreement
[FlexE-IA].
3.5. Neighbour Discovery and Link Property Correlation
There are potential interworking problems between different FlexE
capable equipment. Devices or equipments might not be able to
support the interworking of every slot due to the constraints of
transport network equipment or other constraints. In this case, two
directly connected FlexE capable equipments SHOULD run the neighbour
discovery process and correlate the link property to make sure which
slots are unavailable, which slots can be used by the client.
Neighbour discovery protocol can be communicated in in-band FlexE
section management channel, and also can be communicated through out-
of-band management channel.
3.6. Routing and Topology Dissemination
The topology and routing information is used by the path computation
entity to compute an end-to-end path. Besides the basic
interconnected information, there are also some FlexE specific
attributes that should be taken into consideration.
Partial-rate: partial-rate capability is a special feature which
allows an equipment to discard unavailable slots and transfers the
left slots across OTN transport network. Path computation entity
is more likely to compute a feasible path if this capability is
taken into consideration when computing path.
Unavailable slot information: this information is used to indicate
certain slots SHOULD not be considered when computing an end-to-
Wang, et al. Expires January 9, 2017 [Page 11]
Internet-Draft GMPLS FlexE Framework July 2016
end path. The unavailable slots can not be used to forward signal
because of the transport constraints.
Unused slot information: unused slot can be allocated to the path
as available resource.
3.7. Resizing of FlexE
Currently, OIF has many contributions about the FlexE at the PHY
level and intends to do the resizing process through data plane
negotiation scheme. This framework draft will include this
requirement later when the work is stable in OIF.
4. Control-Plane Requirements
The control of FlexE networks brings some new additional requirements
to the GMPLS protocols. This section summarizes those requirements
for signalling,routing and Link management protocol.
4.1. Support for Signalling of FlexE
Aim of the signaling is to set up an end-to-end LSP for FlexE signal.
The signalling procedures shall be able to assign FlexE releated
attributes for an LSP, which include FlexE group number for a FlexE
LSP. This FlexE group number is unique and can be used to indicate a
group of Ethernet PHYs bonded together.
The signalling procedures shall be able to assign an unique PHY
number for each bonded Ethernet PHY, and a correlation relationship
SHOULD also be indicated between the assigned PHY number and real
physical port number when signalling.
The signalling procedures shall be able to configure the slots
information allocated for a FlexE LSP.
The Signalling procedures shall be able to indicate the palace where
partial-rate mapping happens.
4.2. Support for Routing of FlexE
The routing protocol extensions are mainly based on the functionality
that is described in [RFC4202] and these extensions are made to fit
into FlexE network.
The routing protocol SHALL distribute sufficient information to
compute paths to enable the signalling procedure to establish LSPs as
described in the previous sections.
Wang, et al. Expires January 9, 2017 [Page 12]
Internet-Draft GMPLS FlexE Framework July 2016
The routing protocol SHALL update its advertisements of available
resources and capabilities to include the partial-rate support
information and unused slot information on each Ethernet PHY port.
4.3. Support for Neighbour Discovery and Link Property and Link
Correlation
The control plane MAY include support for neighbour discovery such
that a FlexE network can be constructed in a "plug-and-play" manner.
The control plane SHOULD allow the nodes at opposite ends of a link
to correlate the properties that they will apply to the link. Such a
correlation SHOULD include at least the identities of the nodes and
the identities that they apply to the link. Other FlexE specific
properties, such as the link characteristics of unavailable slot
information, SHOULD also be correlated. Such neighbour discovery and
link property correlation, if provided, MUST be able to operate in
both in-band and out-of-band manner.
5. Security Considerations
TBD
6. Manageability Considerations
TBD
7. References
7.1. Normative References
[FlexE-IA]
Stephen, J. and David. R. Stauffer, "FlexE Implementation
Agreement", 2016.
[I-D.hussain-ccamp-flexe-usecases]
Hussain, I., Valiveti, R., and K. Pithewan, "FlexE
Usecases", draft-hussain-ccamp-flexe-usecases-01 (work in
progress), July 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
Wang, et al. Expires January 9, 2017 [Page 13]
Internet-Draft GMPLS FlexE Framework July 2016
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>.
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description",
RFC 3471, DOI 10.17487/RFC3471, January 2003,
<http://www.rfc-editor.org/info/rfc3471>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
DOI 10.17487/RFC3473, January 2003,
<http://www.rfc-editor.org/info/rfc3473>.
[RFC3603] Marshall, W., Ed. and F. Andreasen, Ed., "Private Session
Initiation Protocol (SIP) Proxy-to-Proxy Extensions for
Supporting the PacketCable Distributed Call Signaling
Architecture", RFC 3603, DOI 10.17487/RFC3603, October
2003, <http://www.rfc-editor.org/info/rfc3603>.
[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions
in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005,
<http://www.rfc-editor.org/info/rfc4202>.
[RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005,
<http://www.rfc-editor.org/info/rfc4203>.
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204,
DOI 10.17487/RFC4204, October 2005,
<http://www.rfc-editor.org/info/rfc4204>.
7.2. Informative References
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3945,
DOI 10.17487/RFC3945, October 2004,
<http://www.rfc-editor.org/info/rfc3945>.
Authors' Addresses
Wang, et al. Expires January 9, 2017 [Page 14]
Internet-Draft GMPLS FlexE Framework July 2016
Qilei Wang (editor)
ZTE
Nanjing
CN
Email: wang.qilei@zte.com.cn
Iftekhar Hussain (editor)
Infinera
Sunnyvale
USA
Email: IHussain@infinera.com
Khuzema Pithewan
Infinera
Sunnyvale
USA
Email: kpithewan@infinera.com
Radha Valiveti
Infinera
Sunnyvale
USA
Email: rvaliveti@infinera.com
Wang, et al. Expires January 9, 2017 [Page 15]