Network Working Group Fatai Zhang
Internet Draft Huawei
Category: Standards Track O. Gonzalez de Dios
Telefonica Investigacion y Desarrollo
G. Bernstein
Grotto Networking
Expires: September 7, 2011 March 7, 2011
Applicability of Generalized Multiprotocol Label Switching (GMPLS)
User-Network Interface (UNI)
draft-zhang-ccamp-gmpls-uni-app-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 7, 2011.
Abstract
Generalized Multiprotocol Label Switching (GMPLS) defines a series of
protocols for the creation of Label Switched Paths (LSPs) in various
switching technologies. The GMPLS UNI was developed in [RFC4208] in
order to be applied to an overlay network model.
Zhang Expires September 2011 [Page 1]
draft-zhang-ccamp-gmpls-uni-app-00.txt March 2011
This document examines a number of GMPLS UNI application scenarios.
It shows how techniques developed after the GMPLS UNI can be applied
to automate or enable critical processes for these applications. This
document also suggested simple extensions to existing technologies to
further enable the UNI and points out some existing unresolved issues.
Conventions used in this document
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 [RFC2119].
Table of Contents
1. Introduction ................................................. 3
2. Terminology .................................................. 4
3. UNI Addressing ............................................... 4
4. UNI Auto Discovery ........................................... 5
5. UNI Path Computation ......................................... 6
5.1. UNI Link Selection ...................................... 6
6. UNI Path Provisioning ........................................ 7
6.1. Flat Model .............................................. 7
6.2. Stitching Model ......................................... 8
6.3. Hierarchy Model ......................................... 9
7. UNI Recovery ................................................. 9
7.1. End-to-end Recovery .................................... 10
7.1.1. Serial Provisioning of Working & Protection Path .. 10
7.1.2. Concurrent Computation of Working & Protection Path 11
7.2. Segment Recovery ....................................... 11
8. UNI Call .................................................... 12
8.1. Exchange of UNI Link Information ....................... 12
8.2. Control of Call Route .................................. 13
9. UNI Multicast ............................................... 13
9.1. UNI Multicast Connection Provisioning .................. 15
10. Security Considerations .................................... 15
11. IANA Considerations ........................................ 15
12. Acknowledgments ............................................ 15
13. References ................................................. 16
14. Authors' Addresses ......................................... 18
Zhang Expires September 2011 [Page 2]
draft-zhang-ccamp-gmpls-uni-app-00.txt March 2011
1. Introduction
Generalized Multiprotocol Label Switching (GMPLS) defines a series of
protocols, including Open Shortest Path Fist - Traffic Engineering
(OSPF-TE) and Resource ReserVation Protocol - Traffic Engineering
(RSVP-TE), which can be used to create Label Switched Paths (LSPs) in
a number of deployment scenarios with various transport technologies.
The User-Network Interface (UNI) reference point is defined in the
Automatically Switched Optical Network (ASON) [G.8080]. The GMPLS
overlay model, as per [RFC4208], can be applied at the UNI, as shown
in Figure 1.
Overlay Overlay
Network +----------------------------------+ Network
+---------+ | | +---------+
| +----+ | | +-----+ +-----+ +-----+ | | +----+ |
| | | | UNI | | | | | | | | UNI | | | |
| -+ EN1+-+-----+--+ CN1 +----+ CN2 +----+ CN3 +---+-----+-+ EN3+- |
| | | | +--+--+ | | | | | | | | | |
| +----+ | | | +--+--+ +--+--+ +--+--+ | | +----+ |
| | | | | | | | | |
+---------+ | | | | | | +---------+
| | | | | |
+---------+ | | | | | | +---------+
| | | | +--+--+ | +--+--+ | | |
| +----+ | | | | | +-------+ | | | +----+ |
| | +-+--+ | | CN4 +---------------+ CN5 | | | | | |
| -+ EN2+-+-----+--+ | | +---+-----+-+ EN4+- |
| | | | UNI | +-----+ +-----+ | UNI | | | |
| +----+ | | | | +----+ |
| | +----------------------------------+ | |
+---------+ Core Network +---------+
Overlay Overlay
Network Network
Figure 1 - Applying GMPLS overlay model at UNI
Assume that there is an end-to-end UNI connection passing through
EN1-CN1-CN2-CN3-EN3. For convenience, some terms used in this
document are defined below:
- "source EN" refers to the edge-node who initiates the connection
(e.g., EN1);
- "destination EN" refers to the edge-node where the connection is
terminated (e.g., EN3);
Zhang Expires September 2011 [Page 3]
draft-zhang-ccamp-gmpls-uni-app-00.txt March 2011
- "ingress CN" refers to the core-node to which the source EN is
attached (e.g., CN1);
- "egress CN" refers to the core-node to which the destination EN
is attached (e.g., CN3).
[RFC4208] provides mechanisms for UNI signaling, which are compatible
with GMPLS RSVP-TE signaling ([RFC3471] and [RFC3473]). A single end-
to-end RSVP session between source EN and destination EN is used for
the user connection, which is similar to connection creation between
two core nodes. When considering the isolation of topology
information between core network and the overlay network, additional
processing of the ERO and RRO is required. For example, the ingress
CN should verify the ERO it received against its topology database
before forwarding the PATH message. And the ingress/egress CN may
edit or remove the RRO in order to hide the path segment used inside
the core network from the EN.
The UNI can be used in many application scenarios. For example, in a
multi-layer network, the interface between client layer node and
server layer node can be seen as a UNI. Or, when deploying VPN
services, users can connect to a service provider network via UNI.
This document examines a number of current and future GMPLS
application scenarios. It shows how techniques developed after the
GMPLS UNI was developed can be used to automate or enable critical
aspects of these application scenarios. It points out some potential
technology extensions that could improve UNI operation, and
highlights some existing unresolved issues.
2. Terminology
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 [RFC2119].
3. UNI Addressing
In [RFC4208], the GMPLS overlay model is applied at the UNI reference
point, and it is required that the edge-node and its attached core-
node of the overlay network share the same address space that is used
by GMPLS to signal between the edge-nodes across the core network.
Under this condition, the user connection can be created using a
Zhang Expires September 2011 [Page 4]
draft-zhang-ccamp-gmpls-uni-app-00.txt March 2011
single end-to-end RSVP session, which is consistent with the RSVP
model. Therefore, RSVP-TE defined in [RFC3473] can be used for
support GMPLS UNI without any extensions.
However, in the practical deployment of GMPLS UNI, the requirement of
sharing the same address space between EN and its attached CN may not
be satisfied if the core network and the overlay network are designed
and deployed separately, especially if the two networks belong to
different carriers. For example, the core network may use IPv6
addresses, while the overlay network uses IPv4 addresses. Or, since
the core network is a closed system, the assignment of the IP
addresses of the CNs is independent of other IP addresses outside the
core network. This implies that the nodes in the core network may use
addresses which collide with the edge nodes in the overlay network.
In the cases above, due to the address space incompatibility issues,
the RSVP-TE [RFC3473] session may not be used to create the UNI
connection. Hence [RFC4208] needs to be extended to support the
different address space between Core network and Overlay network.
4. UNI Auto Discovery
In most cases, the source EN does not have the knowledge of which CN
the destination EN is attached and TE information concerning the
destination UNI link. When creating the connection, information about
the destination EN is carried in the signaling message sent to the
ingress CN.
The ingress CN is then responsible for resolving the address of the
egress CN based on the destination EN information and examine whether
there is sufficient resources on the destination UNI link. In other
words, the CN should have the mapping relationship between CNs and
ENs and the TE information of the corresponding UNI links. Therefore,
some kind of UNI auto discovery or manual configuration is required.
We can avoid manual configuration if the UNI is applied in a Layer 1
Virtual Private Network (L1VPN, [RFC4847]) scenario. In this case the
auto discovery of UNI using OSPFv2 is provided in [RFC5252]. A new
L1VPN LSA is introduced to advertise the L1VPN information via the
L1VPN info TLV and the TE information of the CE-PE link (in the
language of UNI, it's the EN-CN link) via the TE link TLV.
Zhang Expires September 2011 [Page 5]
draft-zhang-ccamp-gmpls-uni-app-00.txt March 2011
5. UNI Path Computation
The end-to-end UNI path computation includes three parts: the
selection of source UNI link, the path computation inside the core
network and the selection of destination UNI link.
The selection of UNI link may not necessary in some scenarios. One
example is in case of single-homing with only one UNI link between EN
and CN, and another example is manual selection of UNI link. In such
cases, the CN to which the source EN is attached, or the PCE
([RFC4655]) which is responsible for the core network, can perform
the path computation for traversing the core network when the UNI
signaling sent from the source EN reaches to the CN.
5.1. UNI Link Selection
The source EN does not have the topology and TE information of the
core network in the overlay model. Therefore, in the case of multi-
homing, the source EN does not have enough information to make a
correct choice among all the UNI links between itself and the core
network for an optimal end-to-end connection.
In this case, a PCE whose computation domain covers both the core
network and the ENs attached to it can be used. Note that the GMPLS
UNI predates PCE and hence a PCE was not available to solve this
problem in early GMPLS UNI deployments. The PCE can use the UNI
discovery mechanism described in Section 4. to learn the EN-CN
relationship and the TE information of the UNI links, and therefore
has the ability to select the optimal UNI link for the connection.
Figure 2 shows an example of UNI path computation. The PCE can help
the source EN to compute the end-to-end connection when the UNI path
computation request is received, so that the source EN can learn
which UNI link to be selected.
Zhang Expires September 2011 [Page 6]
draft-zhang-ccamp-gmpls-uni-app-00.txt March 2011
1) PCReq: EN1-EN2 +-----+
+------------------------>| |
| | PCE |
| +----------------------| |
| | +-----+
| | 2) PCRep: EN1-CN4-CN5-CN6-EN2
| |
| | +----------------------------------+
| | | Core Network |
| | | +----+ +----+ +----+ |
| V +----+--+ CN1+------+ CN2+------+ CN3+--+----+
+----+ | | +--+-+ +--+-+ +--+-+ | | +----+
| +--+ | | | | | +--+ |
| EN1| UNI | | | | | UNI | EN2|
| +--+ | | | | | +--+ |
+----+ | | +--+-+ +--+-+ +--+-+ | | +----+
+----+--+ CN4+------+ CN5+------+ CN6+--+----+
---------> | +----+ +----+ +----+ |
3) Signaling +----------------------------------+
Figure 2 - PCE for UNI path computation
In cases where the confidentiality of the topology within the core
network needs to be preserved, the Path Key Subobject (PKS) can be
used (See [RFC5520] and [RFC5553]). In the PCRep message returned to
EN1, the Confidential Path Segment (CPS) (i.e., CN4-CN5-CN6) is
encoded as a PKS by the PCE. Therefore, the EN1 only learns the
selected UNI link from PCE. When receiving the UNI signaling carrying
the PKS from EN1, CN4 can request the PCE to decode the PKS and then
continue to create the connection.
Note that the PCE should be visible to the ENs and there should be
control channel between PCE and EN for the transmission of PCEP
messages. An alternative implementation could be that the PCE is
located inside each CN to which the source EN is attached, so that
the source EN can use the UNI control channel to send and receive the
PCEP messages.
6. UNI Path Provisioning
The basic GMPLS UNI application is to provide end-to-end connections
between edge-nodes through a core network via the overlay model.
6.1. Flat Model
The edge-nodes may have the same switching capability and switching
capacity as the nodes in the core network. In this case, one single
Zhang Expires September 2011 [Page 7]
draft-zhang-ccamp-gmpls-uni-app-00.txt March 2011
end-to-end RSVP session through the edge-nodes and a series of core-
nodes can be used to create the connection, which forms a flat LSP
model (in the language of [RFC5251], such end-to-end RSVP session is
called Shuffling Session), as shown in Figure 3.
+----------------------------------+
| Core Network |
| |
+----+ UNI | +----+ +----+ +----+ | UNI +----+
| EN +-------+--+ CN +------+ CN +------+ CN +--+-------+ EN |
+----+ | +----+ +----+ +----+ | +----+
| | | |
| +----------------------------------+ |
| |
|<------------- End-to-end RSVP Session -------------->|
| |
Figure 3 - Flat model
If the edge-nodes and their attached core-nodes share the same
address space, the GMPLS signaling described in [RFC3471], [RFC3473]
and other related standards, with special ERO and RRO processing as
described in [RFC4208], can be used to create a connection.
6.2. Stitching Model
Alternatively, in the above case, the stitching mechanism described
in [RFC5150] can be used to create an LSP segment (S-LSP) between the
ingress and the egress CN, and to stitch the end-to-end UNI
connection to the created S-LSP, as shown in Figure 4.
+----------------------------------+
| Core Network |
| |
+----+ UNI | +----+ +----+ +----+ | UNI +----+
| EN +-------+--+ CN +------+ CN +------+ CN +--+-------+ EN |
+----+ | +----+ +----+ +----+ | +----+
| | | | | |
| +----+------------------------+----+ |
| | | |
| |<-LSP Segment (S-LSP)-->| |
| |
|<------------- End-to-end RSVP Session -------------->|
| |
Figure 4 - Stitching model
Zhang Expires September 2011 [Page 8]
draft-zhang-ccamp-gmpls-uni-app-00.txt March 2011
6.3. Hierarchy Model
In case that the ENs and the CNs have the same switching capability,
a tunnel between the ingress and egress core-nodes can be provisioned.
The tunnel may have a larger capacity than the end-to-end UNI
connection, which may depend on the policies configured at the
ingress of the core network. The end-to-end connection can be nested
into the tunnel, which forms the LSP hierarchy.
Another case is that the edge-nodes have different switching
capabilities with the core network. In such a case, the LSP hierarchy
model should also be used.
+----------------------------------+
| Core Network |
| |
+----+ UNI | +----+ +----+ +----+ | UNI +----+
| EN +-------+--+ CN +======+ CN +======+ CN +--+-------+ EN |
+----+ | +----+ +----+ +----+ | +----+
| | | | | |
| +----+------------------------+----+ |
| | | |
| |<-Core Network Tunnel-->| |
| |
|<------------- End-to-end RSVP Session -------------->|
| |
Figure 5 - Hierarchy model
In the hierarchy model, the end-to-end connection can be divided into
three hops: one for each UNI link and one hop across the core network.
The core network tunnel can be pre-provisioned via network planning,
or triggered by the UNI signal. For the latter case, the [RFC5212],
[RFC6001] and other multi-layer network related standards are
possible to be used to create the hierarchical LSP.
7. UNI Recovery
One of the significant uses of GMPLS is to provide recovery
mechanisms for connections, which is also needed in many UNI
scenarios.
Zhang Expires September 2011 [Page 9]
draft-zhang-ccamp-gmpls-uni-app-00.txt March 2011
7.1. End-to-end Recovery
In the case of multi-homing, UNI end-to-end recovery is possible. As
shown in Figure 6, the working path (W) and the protection path (P)
are disjoint from each other not only inside the core network, but
also at both the source and destination sides of the UNI. Mechanisms
need to be provided to ensure the selection of disjoint working and
backup paths.
+----------------------------------+
| Core Network |
| |
W | +----+ +----+ +----+ |
+----+--+ CN +------+ CN +------+ CN +--+----+
+----+ | | +----+ +----+ +----+ | | +----+
| +--+ | | +--+ |
| EN | UNI | | UNI | EN |
| +--+ | | +--+ |
+----+ | | +----+ +----+ +----+ | | +----+
+----+--+ CN +------+ CN +------+ CN +--+----+
P | +----+ +----+ +----+ |
+----------------------------------+
Figure 6 - UNI end-to-end recovery
7.1.1. Serial Provisioning of Working & Protection Path
In the case that the working path is computed and created before the
protection path, path computation needs to compute a disjoint (or
maximally disjoint) protection path given this existing working path.
If the information concerning the working path segment traversing the
core network is known by the EN without considering the
confidentiality, then the EN can easily use the RRO to collect the
working path information, and use the XRO to exclude the working path
when creating the protection path, as described in [RFC4874].
But in most cases, in order to preserve the confidentiality of
topology within the core network, the information of path segment
traversing the core network should be hidden from the EN. In such
case, the RRO & XRO mechanism in [RFC4874] cannot be used. An
alternative would be to only collect the Shared Risk Group (SRG)
information but not the full path information. This is because the
SRG information is normally less confidential than the information of
Zhang Expires September 2011 [Page 10]
draft-zhang-ccamp-gmpls-uni-app-00.txt March 2011
node ID and link ID and can be allowed to be known outside the core
network.
In an application scenario where a PCE is involved inside the core
network, then the Path Key mechanism can be used. The confidential
path segment, i.e., the working path segment traversing the core
network, is encoded as a PKS by the PCE when computing the working
path. This PKS can be brought to the source EN, so when it request
that the PCE compute a protection path, the PKS can be used to
exclude the working path segment inside the core network.
[RFC5520] provides a mechanism to hide the CPS using PKS in the PCEP
message, while [RFC5553] makes extensions to RSVP-TE to carry the PKS
in ERO and RRO objects. It is required that the PKS should also be
allowed to be carried in the XRO in both PCEP message and RSVP-TE
signaling.
7.1.2. Concurrent Computation of Working & Protection Path
Alternatively, the working and protection path can be computed at the
same time (e.g., by PCE or by one of the CNs to which the source EN
is attached).
[PCE-GMPLS] allows requesting the PCE for path computation with
specified protection type defined in [RFC4872]. Therefore, it's
possible that the source EN requests the edge CN or PCE to compute
both the working and the protection path at the same time. At this
time, the disjunction problem can be resolved inside the path
computation server.
Same as described in the previous section, the path segment
traversing the core network can be encoded as a PKS if
confidentiality is requested.
7.2. Segment Recovery
The UNI connection may only request protection inside the core
network, especially in case of single-homing. One UNI segment
protection example is shown in Figure 7.
Zhang Expires September 2011 [Page 11]
draft-zhang-ccamp-gmpls-uni-app-00.txt March 2011
+--------------------------------------+
| Core Network |
| W +----+ +----+ |
| +--+ CN +--+ CN +--+ |
+----+ | +----+ | +----+ +----+ | +----+ | +----+
| | | | +--+ +--+ | | | |
| EN +-----+-+ CN | | CN +-+-----+ EN |
| | UNI | | +--+ +--+ | | UNI | |
+----+ | +----+ | +----+ +----+ | +----+ | +----+
| +--+ CN +--+ CN +--+ |
| P +----+ +----+ |
+--------------------------------------+
Figure 7 - UNI segment recovery
[RFC4873] provides the mechanism of segment recovery, in which the
PROTECTION Object is extended to indicate the segment recovery, and
the SERO object is introduced for the explicit control of the
protection LSP between the branch node and the merge node.
However, due to the overlay model, the source EN may not have the
information concerning the CN to which the destination EN is attached.
In other words, the source EN does not know which node is the merge
node of the UNI segment protection, so the SERO object cannot be used
to request the edge CN for the UNI segment recovery. Therefore,
segment recovery may not be controlled explicitly by the source EN.
8. UNI Call
The GMPLS Call, defined in [RFC4974], provides a mechanism to
negotiate agreement between endpoints possibly in cooperation with
the nodes that provide access to the network. Typically the GMPLS
Call can be applied in the UNI scenario for access link capability
exchange, policy, authorization, security, and so on.
8.1. Exchange of UNI Link Information
It is possible that the TE attributes of the access link (i.e., the
UNI link) are not shared across the core network. So the source EN
may not have the TE information of the destination access link as
well as the capability of the destination EN. For example, in case of
TDM network, the VCAT/LCAS capability of the destination EN may not
be known.
In this case, the source EN can raise a Call carrying the
Zhang Expires September 2011 [Page 12]
draft-zhang-ccamp-gmpls-uni-app-00.txt March 2011
LINK_CAPABILITY object to have a capability exchange with the
destination EN, as described in [RFC4974].
8.2. Control of Call Route
When applying the Call, it's possible that there are multiple core
network domains between the source EN (Call initiator) and the
destination EN (Call terminator), or there is more than one Call
manager in the core network (e.g., in the multi-homing scenario where
the CNs to which the ENs are attached act as the Call managers).
In the both cases, when establishing the Call, there may be multiple
alternative routes for the Call message to reach the destination EN.
One can simply use the hop-by-hop manner (i.e., each Call manager
determines the next Call manager to which the Call message will be
sent by itself) to control the path of the Call.
However, in the practical deployment of UNI Call, commercial and
policy motivations normally play an important role in selecting the
Call route, especially in the multi-domain scenario. In this case,
the hop-by-hop manner is not practical because the route of the Call
needs to be pre-determined in consideration of commercial and policy
factors before establishing the Call.
Therefore, it is desirable to allow full control of the Call by the
source EN. That is, the source EN can identify the full Call route
and signal it explicitly, so that the Call message can be forwarded
along the desired route. Moreover, the management plane needs to be
able to identify the Call route explicitly as an instruction to the
source EN.
9. UNI Multicast
There is desired to support point-to-multipoint (P2MP) TE LSPs from
one source EN to multiple leaf ENs.
There are two cases for the UNI multicast. For the first case, only
the ingress and egress CNs in the core network support the multicast.
The core network has to provide multiple P2P connections between
ingress CN and each egress CN for the end-to-end UNI multicast, as
shown in Figure 8.
For example, in the PSC over TDM multi-layer scenario, the
ingress/egress CNs may have the packet multicast capability and
therefore can adapt the packets from EN into multiple TDM connections
Zhang Expires September 2011 [Page 13]
draft-zhang-ccamp-gmpls-uni-app-00.txt March 2011
inside the core network, while other CNs inside the core network may
only support point-to-point (P2P) TDM connections.
+----------------------------------------+
| Core Network |
| +-----+ +-----+ +-----+ |UNI +---+
+---+ UNI| | +--------+-----+-------+ +--+----+EN2|
|EN1+----+--+ CN1 +--------+-\CN2| | CN3 | | +---+
+---+ | | +--------+\ \ | | | | Leaf A
Source | +-----+ +-+-+-+ +-----+ |
| | | |
| +-+-+-+ +-----+ |UNI +---+
| | | \+-------+ +--+----+EN3|
| | |CN4| | CN5 | | +---+
| +-+---+ +-----+ | Leaf B
| | |
| +-+---+ +-----+ |UNI +---+
| | \---+-------+ +--+----+EN4|
| | CN6 | | CN7 | | +---+
| +-----+ +-----+ | Leaf C
+----------------------------------------+
Figure 8 - Only ingress/egress CNs support multicast
In another case, all the CNs in the core network can support
multicast, so that the core network can create a P2MP LSP to provide
the end-to-end UNI multicast, as shown in Figure 9.
+----------------------------------------+
| Core Network |
| +-----+ +-----+ +-----+ |UNI +---+
+---+ UNI| | +--------+-+-->+-------+ +--+----+EN2|
|EN1+----+--+ CN1 | | |CN2| | CN3 | | +---+
+---+ | +-----+ +-V---+ +-----+ | Leaf A
Source | | |
| +-+---+ +-----+ |UNI +---+
| | +-->+-------+ +--+----+EN3|
| | |CN4| | CN5 | | +---+
| +-V---+ +-----+ | Leaf B
| | |
| +-+---+ +-----+ |UNI +---+
| | \-->+-------+ +--+----+EN4|
| | CN6 | | CN7 | | +---+
| +-----+ +-----+ | Leaf C
+----------------------------------------+
Figure 9 - All CNs support multicast
Zhang Expires September 2011 [Page 14]
draft-zhang-ccamp-gmpls-uni-app-00.txt March 2011
For example, in the Ethernet over OTN scenario, if the core network
can support ODU0 multicast, then an ODU0 P2MP LSP can be created
inside the core network to carry the client Gigabit Ethernet (GE)
signal for the ENs.
9.1. UNI Multicast Connection Provisioning
The three UNI connection provisioning models, as described in Section
6, should also be applied in the UNI multicast scenario.
For the flat model, one end-to-end P2MP session as described in
[RFC4875] can be used directly to create the P2MP LSP from source EN
to leaf ENs.
For the stitching model, multiple P2P LSP segments or one P2MP LSP
segment between the ingress CN and each egress CNs needs to be
created and then stitched to the UNI P2MP LSP. GMPLS UNI signaling
should have the capability to convey the multicast information by
using stitching model.
For the hierarchy model, multiple P2P LSP tunnels or one P2MP LSP
tunnel between the ingress CN and each egress CNs needs be triggered
by the UNI signaling for creating P2MP LSP. GMPLS UNI signaling
should have the capability to convey the multicast information by
using hierarchy model.
10. Security Considerations
TBD.
11. IANA Considerations
This informational document does not make any requests for IANA
action.
12. Acknowledgments
TBD.
Zhang Expires September 2011 [Page 15]
draft-zhang-ccamp-gmpls-uni-app-00.txt March 2011
13. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004.
[RFC3209] D. Awduche et al, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC3209, December 2001.
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC
3471, January 2003.
[RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
3473, January 2003.
[RFC4208] G. Swallow et al, "Generalized Multiprotocol Label
Switching (GMPLS) User-Network Interface (UNI): Resource
ReserVation Protocol-Traffic Engineering (RSVP-TE)
Support for the Overlay Model", RFC4208, October 2005.
[G.8080] ITU-T Rec. G.8080/Y.1304, "Architecture for the
Automatically Switched Optical Network (ASON)," June 2006
(and Amend.2, September 2010).
[RFC5150] A. Ayyangar et al, "Label Switched Path Stitching with
Generalized Multiprotocol Label Switching Traffic
Engineering (GMPLS TE)", RFC5150, February 2008.
[RFC5212] K. Shiomoto et al, "Requirements for GMPLS-Based Multi-
Region and Multi-Layer Networks (MRN/MLN)", RFC5212, July
2008.
[RFC5339] JL. Le Roux et al, "Evaluation of Existing GMPLS
Protocols against Multi-Layer and Multi-Region Networks
(MLN/MRN)", RFC5339, September 2008.
[RFC4874] CY. Lee et al, "Exclude Routes - Extension to Resource
ReserVation Protocol-Traffic Engineering (RSVP-TE)",
RFC4874, April 2007.
Zhang Expires September 2011 [Page 16]
draft-zhang-ccamp-gmpls-uni-app-00.txt March 2011
[RFC6001] Dimitri Papadimitriou et al, "Generalized Multi-Protocol
Label Switching (GMPLS) Protocol Extensions for Multi-
Layer and Multi-Region Networks (MLN/MRN)", RFC6001,
October, 2010.
[RFC4206] K. Kompella et al, "Label Switched Paths (LSP) Hierarchy
with Generalized Multi-Protocol Label Switching (GMPLS)
Traffic Engineering (TE)", RFC4206, October 2005.
[RFC6107] K. Shiomoto, A. Farrel, "Procedures for Dynamically
Signaled Hierarchical Label Switched Paths", RFC6107,
February 2011.
[RFC4847] T. Takeda, Ed., "Framework and Requirements for Layer 1
Virtual Private Networks", RFC4847, April 2007.
[RFC5251] D. Fedyk and Y. Rekhter, Ed., "Layer 1 VPN Basic Mode",
RFC5251, July 2008.
[RFC5252] I. Bryskin and L. Berger Ed., "OSPF-Based Layer 1 VPN
Auto-Discovery", RFC5252, July 2008.
[RFC4655] A. Farrel et al, "A Path Computation Element (PCE)-Based
Architecture", RFC4655, August 2006.
[RFC5520] R. Bradford, Ed., "Preserving Topology Confidentiality in
Inter-Domain Path Computation Using a Path-Key-Based
Mechanism", RFC5520, April 2009.
[RFC5553] A. Farrel, Ed., "Resource Reservation Protocol (RSVP)
Extensions for Path Key Support", RFC5553, May 2009.
[PCE-GMPLS] C. Margaria et al, "PCEP extensions for GMPLS", draft-
ietf-pce-gmpls-pcep-extensions-01.txt, October 24, 2010
[RFC4872] J.P. Lang et al, "RSVP-TE Extensions in Support of End-
to-End Generalized Multi-Protocol Label Switching (GMPLS)
Recovery", RFC4872, May 2007.
[RFC4873] L. Berger et al, "GMPLS Segment Recovery", RFC4873, May
2007.
[SRLG-FA] Fatai Zhang et al, "RSVP-TE Extensions for Configuration
SRLG of an FA", draft-zhang-ccamp-srlg-fa-configuration-
01.txt, October 20, 2010.
Zhang Expires September 2011 [Page 17]
draft-zhang-ccamp-gmpls-uni-app-00.txt March 2011
[RFC4974] D. Papadimitriou and A. Farrel, Ed., "Generalized MPLS
(GMPLS) RSVP-TE Signaling Extensions in Support of Calls",
RFC4974, August 2007.
[Call-ext] Fatai Zhang et al, "RSVP-TE extensions to GMPLS Calls",
draft-zhang-ccamp-gmpls-call-extensions-01.txt, July 08,
2009.
[RFC4461] S. Yasukawa, Ed., "Signaling Requirements for Point-to-
Multipoint Traffic-Engineered MPLS Label Switched Paths
(LSPs)", RFC4461, April 2006.
[RFC4875] R. Aggarwal et al, "Extensions to Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Multipoint TE Label Switched Paths (LSPs)", RFC4875, May
2007.
14. Authors' Addresses
Fatai Zhang
Huawei Technologies
F3-5-B R&D Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129 P.R.China
Phone: +86-755-28972912
Email: zhangfatai@huawei.com
Oscar Gonzalez de Dios
Telefonica Investigacion y Desarrollo
Emilio Vargas 6
Madrid, 28045
Spain
Phone: +34 913374013
Email: ogondio@tid.es
Greg M. Bernstein
Grotto Networking
Fremont California, USA
Phone: (510) 573-2237
Email: gregb@grotto-networking.com
Zhang Expires September 2011 [Page 18]
draft-zhang-ccamp-gmpls-uni-app-00.txt March 2011
Yi Lin
Huawei Technologies
F3-5-B R&D Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129 P.R.China
Phone: +86-755-28972914
Email: yi.lin@huawei.com
Young Lee
Huawei Technologies
1700 Alma Drive, Suite 100
Plano, TX 75075
USA
Phone: (972) 509-5599 (x2240)
Email: leeyoung@huawei.com
Dan Li
Huawei Technologies
F3-5-B R&D Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129 P.R.China
Phone: +86-755-28973237
Email: huawei.danli@huawei.com
Intellectual Property
The IETF Trust takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology
described in any IETF Document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights.
Copies of Intellectual Property disclosures made to the IETF
Secretariat and any assurances of licenses to be made available, or
the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers or
Zhang Expires September 2011 [Page 19]
draft-zhang-ccamp-gmpls-uni-app-00.txt March 2011
users of this specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
The definitive version of an IETF Document is that published by, or
under the auspices of, the IETF. Versions of IETF Documents that are
published by third parties, including those that are translated into
other languages, should not be considered to be definitive versions
of IETF Documents. The definitive version of these Legal Provisions
is that published by, or under the auspices of, the IETF. Versions of
these Legal Provisions that are published by third parties, including
those that are translated into other languages, should not be
considered to be definitive versions of these Legal Provisions.
For the avoidance of doubt, each Contributor to the IETF Standards
Process licenses each Contribution that he or she makes as part of
the IETF Standards Process to the IETF Trust pursuant to the
provisions of RFC 5378. No language to the contrary, or terms,
conditions or rights that differ from or are inconsistent with the
rights and licenses granted under RFC 5378, shall have any effect and
shall be null and void, whether published or posted by such
Contributor, or included with or in such Contribution.
Disclaimer of Validity
All IETF Documents and the information contained therein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Zhang Expires September 2011 [Page 20]
draft-zhang-ccamp-gmpls-uni-app-00.txt March 2011
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.
Zhang Expires September 2011 [Page 21]