Internet DRAFT - draft-li-i2rs-mpls-lsps-use-case
draft-li-i2rs-mpls-lsps-use-case
Network Working Group X. Li
Internet-Draft R. Zhang
Intended status: Informational K. Li
Expires: May 18, 2015 S. Chen
Beijing University of Posts and Telecommunications
November 14, 2014
I2RS MPLS LSPs Use Case
draft-li-i2rs-mpls-lsps-use-case-00
Abstract
The Label-switched paths (LSPs) play fundument role in MPLS domain.
Traditionally Label-switched paths (LSPs) are established by the
network operator via CLI, SNMP or NETCONF for a variety of purposes,
such as to create network-based IP virtual private networks or to
route traffic along specified paths through the network. Interface
to the Routing System's (I2RS) Programmatic interfaces provides an
alternate way to create and maintain the LSPs.This document describes
requirement and use case for which I2RS can be used for LSPs
management.
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].
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 May 18, 2015.
Li, et al. Expires May 18, 2015 [Page 1]
Internet-Draft I2RS MPLS LSPs Use Case November 2014
Copyright Notice
Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. LSPs Configure . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. LSPs Connection . . . . . . . . . . . . . . . . . . . . 3
2.2. Capability negotiation . . . . . . . . . . . . . . . . . 5
3. LSPs Events . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Notification of LSP Events . . . . . . . . . . . . . . . 5
3.2. LSPs Statistics . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
The Label Swicth Paths (LSPs) is a fundement element that play key
role for package trsanport in MPLS domain. Traditionally LSP may be
managed via CLI, SNMP or NETCONF.
Interface to Routing System (I2RS) architecture
[I-D.ietf-i2rs-architecture] defines a standard, programmatic
interface to routing system. The I2RS is not intended to replace any
existing configuration mechanisms. Instead, I2RS is intended to
augment those existing mechanisms by defining a standardized set of
programmatic interfaces to enable easier configuration, management
and analysis of the networks source
This document describes requirement and use case for which I2RS can
be used for establishing LSPs connection. The use case described in
this document encompass: LSPs configure, LSPs events.
Li, et al. Expires May 18, 2015 [Page 2]
Internet-Draft I2RS MPLS LSPs Use Case November 2014
2. LSPs Configure
LSPs is fundment element in the MPLS domain's network.By I2RS
interface the network application can setup LSPs through policy
configure.The application can select proper programmatic interface.
2.1. LSPs Connection
The basic stage of LSPs includes establishing, maintaining and
revocation. Paths computation in large MPLS-domain networks is
complex and may require special computational components and
cooperation between the different elements.
Traditionally in order to configure a static LSP that need
configuring the ingress router and each router along the path and
including the egress router.The tasks encompass:Configuring the
Ingress Router,Configuring the Intermediate (Transit) and Egress
Routers and etc. The ingress router computes path according to the
network topology and the request of user , and hop-by- hop down the
request to establish the path.The ingress edge router knows the
current topology of the network,But it does not know the available
resource information of router along the path. so it needs to
establish sessions-by-hop to issue a label request until it reaches
the egress router, and then again along the reverse path established
LSP.In this case, if a router on the path does not meet the
demand,the ingress router accepts the request must recalculate path
or other paths in low service level which have the required router
may be sacrificed in order to meet LSP.
******************** ***************** *****************
* Application LSP * * Application B * * Application C *
******************** ***************** *****************
^ ^ ^
| | |
|--------------| | |--------------|
| | |
v v v
***************
* Client A *
***************
^ ^ ^ ^
| | | |
|-------------| | | |-----------------|
| | | |
| | | |
**************** v ************* | | ***************** v ************
* +---------------------+ * | | * +---------------------+ *
Li, et al. Expires May 18, 2015 [Page 3]
Internet-Draft I2RS MPLS LSPs Use Case November 2014
* | Edge Agent | * | | * | Edge Agent | *
* +---------------------+ * | | * +---------------------+ *
* ^ ^ ^ ^ * | | * ^ ^ ^ ^ *
* | | | | * | | * | | | | *
* v | | v * | | * v | | v *
* +---------+ | | +--------+ * | | * +---------+ | | +--------+ *
* | Routing | | | | Local | * | | * | Routing | | | | Local | *
* | and | | | | Config | * | | * | and | | | | Config | *
* |Signaling| | | +--------+ * | | * |Signaling| | | +--------+ *
* +---------+ | | ^ * | | * +---------+ | | ^ *
* ^ | | | * | | * ^ | | | *
* | |----| | | * | | * | |----| | | *
* v | v v * | | * v | v v *
* +----------+ +------------+ * | | * +----------+ +------------+ *
* | Dynamic | | Static | * | | * | Dynamic | | Static | *
* | System | | System | * | | * | System | | System | *
* | State | | State | * | | * | State | | State | *
* +----------+ +------------+ * | | * +----------+ +------------+ *
* * | | * *
* Routing Element 1 * | | * Routing Element 4 *
******************************** | | ********************************
| |
|---------------| |-----------------|
| |
**************** v ************* ***************** v ************
* +---------------------+ * * +---------------------+ *
* | Agent LSR1 | * * | Agent LSR2 | *
* +---------------------+ * * +---------------------+ *
* ^ ^ ^ ^ * * ^ ^ ^ ^ *
* | | | | * * | | | | *
* v | | v * * v | | v *
* +---------+ | | +--------+ * * +---------+ | | +--------+ *
* | Routing | | | | Local | * * | Routing | | | | Local | *
* | and | | | | Config | * * | and | | | | Config | *
* |Signaling| | | +--------+ * * |Signaling| | | +--------+ *
* +---------+ | | ^ * * +---------+ | | ^ *
* ^ | | | * * ^ | | | *
* | |----| | | * * | |----| | | *
* v | v v * * v | v v *
* +----------+ +------------+ * * +----------+ +------------+ *
* | Dynamic | | Static | * * | Dynamic | | Static | *
* | System | | System | * * | System | | System | *
* | State | | State | * * | State | | State | *
* +----------+ +------------+ * * +----------+ +------------+ *
* * * *
* Routing Element 2 * * Routing Element 3 *
******************************** ********************************
Li, et al. Expires May 18, 2015 [Page 4]
Internet-Draft I2RS MPLS LSPs Use Case November 2014
Figure 1: Use case for MPLS establishing LSPs of I2RS
In the I2RS architecture , edge router agent connected with client in
MPLS domain.To establish an LSP, operator may make a request to edge
router agent, then edge router transmit to client, operator can also
make a request to client. By I2rs architecture , client can get
real-time topology of the entire network and local router resource
view , so client can be computed LSPs according to the demand of
user, and issuing LSR FIB under the corresponding resource
requirements on the path. if there is a resource conflict,client can
coordinate and adjust the paths associated with the LSPs according to
application service level.
2.2. Capability negotiation
LSPs Connection supports some policy configuration which are used to
control the allocation of network source,to avoide the specify
router/switch and acceptance of optimal recommend path and so on.
With I2RS a network operator can push LSPs demand request policy
configuration using a programmatic API from an I2RS client to
specific agent according to the service requirement.
3. LSPs Events
I2RS could provide a publish-subscribe capability to applications to
subscribe state and number of LSPs and related events according to
demand.
3.1. Notification of LSP Events
Some applications adopt LSPs established to carry service and the
end-user would care about the state of such LSPs and hope to know and
the changes of their state immediately .There are many technologies
to detect LSPs failures, such as OAM/RSVP hello,When a LSP failure is
detected, the end-user hope receive the immediately notification.
3.2. LSPs Statistics
There are several statistics related to LSPs like the count of
LSPs.These statistics can help network operators know about the
status of the resources network makes use of.
Some access device has limited capacity resource and need restricting
the maximum capacity of LSP. The network administrator wants to know
whether the current capacity of LSP is close to the maximum capacity.
Li, et al. Expires May 18, 2015 [Page 5]
Internet-Draft I2RS MPLS LSPs Use Case November 2014
The application can set the maximum number of LSPs by I2RS
programmatic API. The application can set the warning threshold too.
When LSPs reaches the threshold the warning message will be triggered
and notify the application in the I2RS client. The operator can take
some action according to the warning message.
4. Security Considerations
The LSPs use cases described in this document assumes use of I2RS's
programmatic interfaces described in the I2RS archtechture mentioned
in [I-D.ietf-i2rs-architecture]. This document does not change the
underlying security issues inherent in the existing.
5. IANA Considerations
This document makes no request of IANA.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007.
6.2. Informative References
[I-D.chen-i2rs-mpls-ldp-usecases]
Chen, X. and Z. Li, "Use Cases for an Interface to LDP
Protocol", draft-chen-i2rs-mpls-ldp-usecases-00 (work in
progress), October 2013.
[I-D.ietf-i2rs-architecture]
Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
Nadeau, "An Architecture for the Interface to the Routing
System", draft-ietf-i2rs-architecture-05 (work in
progress), July 2014.
[I-D.ietf-pce-stateful-pce]
Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
Extensions for Stateful PCE", draft-ietf-pce-stateful-
pce-10 (work in progress), October 2014.
Li, et al. Expires May 18, 2015 [Page 6]
Internet-Draft I2RS MPLS LSPs Use Case November 2014
[I-D.keyupate-i2rs-bgp-usecases]
Patel, K., Fernando, R., Gredler, H., Amante, S., White,
R., and S. Hares, "Use Cases for an Interface to BGP
Protocol", draft-keyupate-i2rs-bgp-usecases-04 (work in
progress), July 2014.
Authors' Addresses
Xin Li
Beijing University of Posts and Telecommunications
No 10, Xitucheng Road, Haidian District
Beijing 100876
China
Email: cplalx@163.com
Rongbo Zhang
Beijing University of Posts and Telecommunications
No 10, Xitucheng Road, Haidian District
Beijing 100876
China
Email: duba213@163.com
Ke Li
Beijing University of Posts and Telecommunications
No 10, Xitucheng Road, Haidian District
Beijing 100876
China
Email: lico200912@163.com
Shanzhi Chen
Beijing University of Posts and Telecommunications
No 10, Xitucheng Road, Haidian District
Beijing 100876
China
Email: chensz@datanggroup.cn
Li, et al. Expires May 18, 2015 [Page 7]
