Internet DRAFT - draft-ali-pce-remote-initiated-lsp-usage
draft-ali-pce-remote-initiated-lsp-usage
PCE Working Group Zafar Ali
Internet Draft Siva Sivabalan
Intended status: Standard Track Clarence Filsfils
Expires: April 20, 2014 Cisco Systems
Robert Varga
Pantheon Technologies
Victor Lopez
Oscar Gonzalez de Dios
Telefonica I+D
Xian Zhang
Huawei
October 21, 2013
Path Computation Element Communication Protocol (PCEP)
Extensions for remote-initiated LSP Usage
draft-ali-pce-remote-initiated-lsp-usage-00.txt
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 April 20, 2014.
Copyright Notice
Copyright (c) 2013 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
Expires January 2014 [Page 1]
Internet-Draft draft-ali-pce-remote-initiated-lsp-usage-00.txt
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s)
controlling the copyright in such materials, this document may not
be modified outside the IETF Standards Process, and derivative
works of it may not be created outside the IETF Standards Process,
except to format it for publication as an RFC or to translate it
into languages other than English.
Abstract
When active stateful PCE is used for managing PCE-initiated LSP,
PCC may not be aware of the intended usage of the LSP (e.g., in a
multi-layer network). PCEP Extensions for PCE-initiated MPLS and
GMPLS LSP Setup specifications do not address this requirement.
This draft addresses the requirement to specify on how PCC should
use the remote initiated LSPs.
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 RFC 2119
[RFC2119].
Table of Contents
1. Introduction ..................................................3
2. Use Cases .....................................................3
2.1. Bandwidth-on-demand .......................................3
3. Remote Initiated LSP Usage Requirement ........................5
4. PCEP extension for PCEP Initiated LSP Usage Specification .....5
4.1. LSP_TUNNEL_INTERFACE_ID Object in LSP Initiate Message ....5
4.2. Communicating LSP usage to Egress node ....................7
5. Security Considerations .......................................7
6. IANA Considerations ...........................................7
6.1. END-POINT Object ..........................................7
7. Acknowledgments ...............................................7
8. References ....................................................7
8.1. Normative References ......................................8
8.2. Informative References ....................................8
Expires January 2014 [Page 2]
Internet-Draft draft-ali-pce-remote-initiated-lsp-usage-00.txt
1. Introduction
[I-D. draft-crabbe-pce-pce-initiated-lsp] and [I-D. draft-ali-
pce-remote-initiated-gmpls-lsp] describe the setup and teardown
of PCE-initiated MPLS and GMPLS LSPs under the active stateful
PCE model, without the need for local configuration on the PCC,
thus allowing for a dynamic network that is centrally controlled
and deployed. However, when an active stateful PCE is used for
managing remote-initiated MPLS or GMPLS LSP, the PCC may not be
aware of the intended usage of the remote-initiated LSP. For
example, the PCC may not know the target IGP instance in which
the remote-initiated LSP is to be used. These requirements are
outlined in Section 3.
This draft addresses the requirement to specify on how PCC
should use the PCEP initiated LSPs. This is achieved by using
LSP_TUNNEL_INTERFACE_ID Object defined in [RFC6107] in PCEP, as
detailed in Section 4. PCEP extensions specified in this
document are equally applicable to PCEP initiated MPLS as well
as GMPLS LSPs.
2. Use Cases
2.1. Bandwidth-on-demand
This use case assumes there is a multi-layer network composed by
routers and optical equipment. In this scenario, there is an
entity, which decides it needs extra bandwidth between two
routers. This certain moment a GMPLS LSP connecting both routers
via the optical network can be established on-the-fly. This
entity can be a router, an active stateful PCE or even the NMS
(with or without human intervention).
Expires January 2014 [Page 3]
Internet-Draft draft-ali-pce-remote-initiated-lsp-usage-00.txt
[See PDF version of the document for Figures]
Figure 1. Bandwidth on demand use case
It is important to note that the bandwidth-on-demand interfaces
and spare bandwidth in the optical network could be shared to
cover many under capacity scenarios in the L3 network. For
example, in this use-case, if we assume all interfaces are 10G
and there is 10G of spare bandwidth available in the optical
network, the spare bandwidth in the optical network can be used
to connect any router, depending on bandwidth demand of the
router network. For example, if there are three routers, it is
not known a priori if the demand will make bandwidth-on-demand
interface at R1 to be connected to bandwidth-on-demand interface
at R2 or R3. For this reason, bandwidth-on-demand interfaces
cannot be pre-provisioned with the IP services that are expected
to carry. Furthermore, in this example, as active stateful PCE
is used for managing PCE-initiated LSP, PCC may not be aware of
the intended usage of the PCE-initiated LSP. Specifically, when
the PCE1 initiated GMPLS tunnel1, PCC does not know the IGP
instance whose demand leads to establishment of the GMPLS
tunnel1 and hence does not know the IGP instance in which the
GMPLS tunnel1 needs to be advertised. Similarly, the PCC does
not know IP address that should be assigned to the GMPLS
tunnel1. In the above example, this IP address is labeled as
TUN-IP-R1 (tunnel IP address at R1). The PCC also does not know
if the tunnel needs to be advertised as forwarding and/ or
routing adjacency and/or to be locally used by the target IGP
instance. Similarly, egress node for GMPLS signaling (R2 node in
this example) may not know the intended usage of the tunnel
(tunnel1 in this example). For example, the R2 node does not
know IP address that should be assigned to the GMPLS tunnel1. In
the above example, this IP address is labeled as TUN-IP-R2
Expires January 2014 [Page 4]
Internet-Draft draft-ali-pce-remote-initiated-lsp-usage-00.txt
(tunnel IP address at R2). Section 4 of this draft addresses the
requirement to specify on how PCC and egress node for signaling
should use the remote initiated LSPs.
3. Remote Initiated LSP Usage Requirement
The requirement to specify usage of the LSP to the PCC includes
but not limited to specification of the following information.
- The target IGP instance for the Remote-initiated LSP needs to
be specified.
- In the target IGP instance, should the PCE-initiated LSP be
advertised as a forwarding adjacency and/ or routing adjacency
and/ or to be used locally by the PCC?
- Should the as Remote-initiated LSP be advertised an IPv4 FA/
RA, IPv6 FA/ RA or as unnumbered FA/ RA.
- If Remote-initiated LSP is to be advertised an IPv4 FA/ RA,
IPv6 FA/ RA, what is the local and remote IP address is to be
used for the advertisement.
4. PCEP extension for PCEP Initiated LSP Usage Specification
The requirement to specify on how PCC should use the PCEP
initiated LSPs in outlined in Section 2. This subsection
specifies PCEP extension used to satisfy this requirement.
4.1. LSP_TUNNEL_INTERFACE_ID Object in LSP Initiate Message
[RFC6107] defines LSP_TUNNEL_INTERFACE_ID Object for
communicating usage of the forwarding or routing adjacency from
the ingress node to the egress node. This document extends the
LSP Initiate (PCInitiate) Message to include
LSP_TUNNEL_INTERFACE_ID object defined in [RFC6107]. Object
class and type for the LSP_TUNNEL_INTERFACE_ID object are as
follows:
Object Name: LSP_TUNNEL_INTERFACE_ID
Object-Class Value: TBA by Iana (suggested value: 40)
Object-type: 1
The contents of this object are identical in encoding to the
contents of the RSVP-TE LSP_TUNNEL_INTERFACE_ID object defined
in [RFC6107] and [RFC3477]. The following TLVs of RSVP-TE
LSP_TUNNEL_INTERFACE_ID object are acceptable in this object.
The PCEP LSP_TUNNEL_INTERFACE_ID object's TLV types correspond
to RSVP-TE LSP_TUNNEL_INTERFACE_ID object's TLV types. Please
Expires January 2014 [Page 5]
Internet-Draft draft-ali-pce-remote-initiated-lsp-usage-00.txt
note that use of TLV type 1 defined in [RFC3477] is not
specified by this document.
TLV TLV
Type Description Reference
-- ------------------------------------------------- ----------
2 IPv4 interface identifier with target IGP instance [RFC6107]
3 IPv6 interface identifier with target IGP instance [RFC6107]
4 Unnumbered interface with target IGP instance [RFC6107]
The meanings of the fields of PCEP LSP_TUNNEL_INTERFACE_ID
object are identical to those defined for the RSVP-TE
LSP_TUNNEL_INTERFACE_ID object. Similarly, meanings of the
fields of PCEP LSP_TUNNEL_INTERFACE_ID object's supported TLV
are identical to those defined for the corresponding RSVP-TE
LSP_TUNNEL_INTERFACE_ID object's TLVs. The following fields have
slightly different usage.
- IPv4 Interface Address field in IPv4 interface identifier
with target IGP instance TLV: This field indicates the local
IPv4 address to be assigned to the tunnel at the PCC (ingress
node for RSVP-TE signaling). In the example use case of
Section 2, IP address TUN-IP-R1 (tunnel IP address at R1) is
carried in this field (if TUN-IP-R1 is a v4 address).
- IPv6 Interface Address field in IPv4 interface identifier
with target IGP instance TLV: This field indicates the local
IPv6 address to be assigned to the tunnel at the PCC (ingress
node for RSVP-TE signaling).
- LSR's Router ID field in Unnumbered interface with target IGP
instance: The PCC SHOULD use the LSR's Router ID in Unnumbered
interface with target IGP instance in advertising the LSP
being initiated by the PCE.
- Interface ID (32 bits) field in unnumbered interface with
target IGP instance: All bits of this field MUST be set to 0
by the PCE server and MUST be ignored by PCC. PCC SHOULD
allocate an Interface ID that fulfills Interface ID
requirements specified in [RFC3477].
When the Ingress PCC receives an LPS Request Message with
LSP_TUNNEL_INTERFACE_ID TLV, it uses the information contained
in the TLV to drive the IGP instance, treatment of the LSP being
initiated in the target IGP instance (e.g., FA, RA or local
usage), the local IPv4 or IPv6 address or router-id for
unnumbered case to be used for advertisement of the LSP being
instantiated.
Expires January 2014 [Page 6]
Internet-Draft draft-ali-pce-remote-initiated-lsp-usage-00.txt
4.2. Communicating LSP usage to Egress node
PCE does not need to send LSP Initiate message to egress node to
communicate LSP usage information. Instead PCC (Ingres signaling
node) uses RSVP-TE signaling mechanism specified in [RFC6107] to
send the LSP usage to Egress node. Specifically, when the
Ingress PCC receives an LPS Request Message with
LSP_TUNNEL_INTERFACE_ID TLV, it SHOULD add
LSP_TUNNEL_INTERFACE_ID object in RSVP TE Path message. For this
purpose, it is RECOMMENDED that the ingress PCC use content of
the LSP_TUNNEL_INTERFACE_ID TLV in LSP Initiate Message in PCEP
to drive LSP_TUNNEL_INTERFACE_ID object in RSVP-TE. This
document does not modify usage of LSP_TUNNEL_INTERFACE_ID Object
in RSVP-TE signaling as specified in [RFC6107].
The egress node uses information contained in the
LSP_TUNNEL_INTERFACE_ID object in RSVP-TE Path message to drive
the IGP instance, treatment of the LSP being initiated in the
target IGP instance (e.g., FA, RA or local usage), the local
IPv4 or IPv6 address or router-id for unnumbered case to be used
for advertisement of the LSP being instantiated.
5. Security Considerations
To be added in future revision of this document.
6. IANA Considerations
6.1. END-POINT Object
This document extends the LSP Initiate Message to include
LSP_TUNNEL_INTERFACE_ID object defined in [RFC6107]. Object
class and type for the LSP_TUNNEL_INTERFACE_ID object are as
follows:
Name Class value Type
---- ----------- ----
LSP_TUNNEL_INTERFACE_ID TBA by Iana (Suggested:40) 1
7. Acknowledgments
The authors would like to thank George Swallow and Jan Medved
for their comments.
8. References
Expires January 2014 [Page 7]
Internet-Draft draft-ali-pce-remote-initiated-lsp-usage-00.txt
8.1. Normative References
[RFC 6107] Shiomoto, K., Ed., and A. Farrel, Ed., "Procedures
for Dynamically Signaled Hierarchical Label Switched
Paths", RFC 6107, February 2011.
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered
Links in Resource ReSerVation Protocol - Traffic
Engineering (RSVP-TE)", RFC 3477, January 2003.
[I-D. draft-crabbe-pce-pce-initiated-lsp] Crabbe, E., Minei, I.,
Sivabalan, S., Varga, R., "PCEP Extensions for PCE-
initiated LSP Setup in a Stateful PCE Model", draft-
crabbe-pce-pce-initiated-lsp, work in progress.
[I-D. draft-ali-pce-remote-initiated-gmpls-lsp] Z. Ali, S.
Sivabalan, C. Filsfils, R. Varga, V. Lopez, O. Dios,
X. Zhang, " Path Computation Element Communication
Protocol (PCEP) Extensions for remote-initiated GMPLS
LSP Setup", draft-ali-pce-remote-initiated-gmpls-lsp,
work in progress.
8.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses
Zafar Ali
Cisco Systems
Email: zali@cisco.com
Siva Sivabalan
Cisco Systems
Email: msiva@cisco.com
Clarence Filsfils
Cisco Systems
Email: cfilsfil@cisco.com
Robert Varga
Pantheon Technologies
Victor Lopez
Telefonica I+D
Email: vlopez@tid.es
Oscar Gonzalez de Dios
Expires January 2014 [Page 8]
Internet-Draft draft-ali-pce-remote-initiated-lsp-usage-00.txt
Telefonica I+D
Email: ogondio@tid.es
Xian Zhang
Huawei Technologies
Email: zhang.xian@huawei.com
Expires January 2014 [Page 9]
