| 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
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.
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].
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.
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.
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.
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.
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 ************
* +---------------------+ * | | * +---------------------+ *
* | 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 *
******************************** ********************************
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.
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.
I2RS could provide a publish-subscribe capability to applications to subscribe state and number of LSPs and related events according to demand.
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.
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.
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.
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.
This document makes no request of IANA.
| [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. |
| [I-D.chen-i2rs-mpls-ldp-usecases] | Chen, X. and Z. Li, "Use Cases for an Interface to LDP Protocol", Internet-Draft draft-chen-i2rs-mpls-ldp-usecases-00, 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", Internet-Draft draft-ietf-i2rs-architecture-05, July 2014. |
| [I-D.ietf-pce-stateful-pce] | Crabbe, E., Minei, I., Medved, J. and R. Varga, "PCEP Extensions for Stateful PCE", Internet-Draft draft-ietf-pce-stateful-pce-10, October 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", Internet-Draft draft-keyupate-i2rs-bgp-usecases-04, July 2014. |