MPLS+
1. Usecases of MPLS Global Label
Publication: IETF Individual Draft
Publication History: 2013-07
Publication URL: https://tools.ietf.org/html/draft-li-mpls-global-label-usecases-00
Description:
As the SDN(Service-Driven Network) technology develops, MPLS global label has been proposed again for new solutions. The document proposes possible usecases of MPLS global label. MPLS global label can be used for identification of the location, the service and the network in different application scenarios. From these usecases we can see that no matter SDN or traditional application scenarios, the new solutions based on MPLS global label can gain advantage over the existing solutions to facilitate service provisions.
2. A Framework of MPLS Global Label
Publication: IETF Individual Draft
Publication History: 2014-07
Publication URL: https://tools.ietf.org/html/draft-li-mpls-global-label-framework-02
Description:
The document defines the framework of MPLS global label including the label allocation method for MPLS global label, the representation of MPLS global label and the process of control plane and data plane for MPLS global label.
3. Framework of Network Virtualization Based on MPLS Global Label
Publication: IETF Individual Draft
Publication History: 2013-10
Publication URL: https://tools.ietf.org/html/draft-li-mpls-network-virtualization-framework-00
Description:
As the virtual network operators develop, it is desirable to provide better network virtualization solutions to facilitate the service provision. In the past years, MPLS plays a key role in the process of implementing network virtualization. This document introduces a new framework to implement network virtualization based on MPLS global label. It can provide the virtualized network topology, nodes and links using MPLS global label which can make up the virtual network.
4. Comparison between Segment Routing and LDP/RSVP-TE
Publication: IETF Individual Draft
Publication History: 2016-03
Publication URL: https://tools.ietf.org/html/draft-li-spring-compare-sr-ldp-rsvpte-01
Description:
Segment Routing has been proposed to cope with the use cases in traffic engineering, fast re-reroute, service chain, etc. This document is to compare Segment Routing with the existing LDP and RSVP-TE. Through the comparison the challenges are clarified for the Segment Routing when deploy in the existing MPLS network.
5. Multi-domain MPLS Deployment Enhancement
Publication: IETF Individual Draft
Publication History: 2013-10
Publication URL: https://tools.ietf.org/html/draft-xu-mpls-multi-domain-deployment-enhancement-00
Description:
MPLS as a mature technology is increasingly deployed in large-scale networks which consists of multiple domains (e.g., IGP areas/levels and even Autonomous Systems). To scale such multi-domain MPLS deployment, the concept of hierarchical LSPs is usually resorted. This document describes an enhancement to such hierarchical multi- domain MPLS deployment architecture that could further improve the scalability of multi-domain MPLS deployment.
6. MPLS Segment Routing over IP
Publication: IETF RFC
Publication History: 2019-12
Publication URL: https://tools.ietf.org/html/rfc8663
Description:
MPLS Segment Routing (SR-MPLS) is a method of source routing a packet through an MPLS data plane by imposing a stack of MPLS labels on the packet to specify the path together with any packet-specific instructions to be executed on it. SR-MPLS can be leveraged to realize a source-routing mechanism across MPLS, IPv4, and IPv6 data planes by using an MPLS label stack as a source-routing instruction set while making no changes to SR-MPLS specifications and interworking with SR-MPLS implementations.
This document describes how SR-MPLS-capable routers and IP-only routers can seamlessly coexist and interoperate through the use of SR-MPLS label stacks and IP encapsulation/tunneling such as MPLS- over-UDP as defined in RFC 7510.
7. Use Cases and Framework of Service-Oriented MPLS Path Programming (MPP)
Publication: IETF Individual Draft
Publication History: 2015-03
Publication URL: https://tools.ietf.org/html/draft-li-spring-mpls-path-programming-01
Description:
Source Packet Routing in Networking (SPRING) architecture for unicast traffic has been proposed to cope with the use cases in traffic engineering, fast re-reroute, service chain, etc. It can leverage existing MPLS dataplane without any modification. In fact, the label stack capability in MPLS would have been utilized well to implement flexible path programming to satisfy all kinds of requirements of service bearing. But in the distributed environment, the flexible programming capability is difficult to implement and always confined to reachability. As the introducing of central control in the network, the flexible MPLS programming capability becomes possible owing to two factors: 1. It becomes easier to allocate label for more purposes than reachability; 2. It is easy to calculate the MPLS path in a global network view. Moreover, the MPLS path programming capability can be utilized to satisfy more requirements of service bearing in the service layer which is defined as service-oriented MPLS path programming. This document defines the concept of MPLS path programming, then proposes use cases, architecture and protocol extension requirements in the service layer for the architecture of Source Packet Routing in Networking (SPRING).
8. Segment Path Programming (SPP)
Publication: IETF Individual Draft
Publication History: 2015-10
Publication URL: https://tools.ietf.org/html/draft-li-spring-segment-path-programming-00
Description:
Segment Routing for unicast traffic has been proposed to cope with the usecases in traffic engineering, fast re-reroute, service chain, etc. The document generalizes more use cases based on segment and proposes the concept of Segment Path Programming. In the field of Segment Path Programming: 1. The Segment used in the programmed segment path is not only used in the forwarding plane, but also used in the control plane. 2. The programmed segment path is not only used in the transport layer, but also used in the service layer. Accordingly this document proposes use cases, architecture and protocol extension requirements for the Segment Path Programming (SPP).
Central Control
1. An Architecture of Central Controlled Interior Gateway Protocol (IGP)
Publication: IETF Individual Draft
Publication History: 2013-10
Publication URL: https://tools.ietf.org/html/draft-li-rtgwg-cc-igp-arch-00
Description:
As the Software Defined Networks (SDN) solution develops, IGP will be extended to support central control. This document introduces an architecture of using IGP for central controlling. Some use cases under this new framework are also discussed. For specific use cases, making necessary extensions in IGP are required.
2. Requirements of Interior Gateway Protocol (IGP) for Central Control
Publication: IETF Individual Draft
Publication History: 2014-07
Publication URL: https://tools.ietf.org/html/draft-li-rtgwg-igp-cc-reqs-00
Description:
Interior Gateway Protocol(IGP) such as IS-IS or OSPF is a fundamental building block for traditional routing system which is based on distributed computation model. Routing in networks based on centralized computation model such as Software Defined Network(SDN) may require special IGP extension to facilitate its operation in multi-domain, multi-region, or multi-layer networks.
This document introduces an architecture of deploying IGP for central-controlled network, but it does not aim to provide a detailed description of all the architectural components. It also specifies a set of functional requirements which can be fulfilled by IGP with proper extension for the central-controlled network.
3. An Architecture of Central Controlled Border Gateway Protocol (BGP)
Publication: IETF Individual Draft
Publication History: 2013-10
Publication URL: https://tools.ietf.org/html/draft-li-idr-cc-bgp-arch-00
Description:
As the Software Defined Networks (SDN) solution develops, BGP is extended to support central control. This document introduces an architecture of using BGP for central controlling. Some use cases under this new framework are also discussed. For specific use cases, making necessary extensions in BGP are required.
4. Architecture for Use of BGP as Central Controller
Publication: IETF Individual Draft
Publication History: 2019-10
Publication URL: https://tools.ietf.org/html/draft-cth-rtgwg-bgp-control-03
Description:
BGP is a core part of a network including Software-Defined Networking (SDN) system. It has the traffic engineering information on the network topology and can compute optimal paths for a given traffic flow across the network.
This document describes some reference architectures for BGP as a central controller. A BGP-based central controller can simplify the operations on the network and use network resources efficiently for providing services with high quality.
5. The Use Cases for Path Computation Element (PCE) as a Central Controller
Publication: IETF WG Draft
Publication History: 2020-03
Publication URL: https://tools.ietf.org/html/draft-ietf-teas-pcecc-use-cases-05
Description:
The Path Computation Element (PCE) is a core component of a Software- Defined Networking (SDN) system. It can compute optimal paths for traffic across a network and can also update the paths to reflect changes in the network or traffic demands. PCE was developed to derive paths for MPLS Label Switched Paths (LSPs), which are supplied to the head end of the LSP using the Path Computation Element Communication Protocol (PCEP).
SDN has a broader applicability than signaled MPLS traffic-engineered (TE) networks, and the PCE may be used to determine paths in a range of use cases including static LSPs, segment routing (SR), Service Function Chaining (SFC), and most forms of a routed or switched network. It is, therefore, reasonable to consider PCEP as a control protocol for use in these environments to allow the PCE to be fully enabled as a central controller.
This document describes general considerations for PCECC deployment and examines its applicability and benefits, as well as its challenges and limitations, through a number of use cases. PCEP extensions required for stateful PCE usage are covered in separate documents.
This is a living document to catalogue the use cases for PCECC. There is currently no intention to publish this work as an RFC.
6. An Architecture for Use of PCE and the PCE Communication Protocol (PCEP) in a Network with Central Control
Publication: IETF RFC
Publication History: 2017-12
Publication URL: https://tools.ietf.org/html/rfc8283
Description:
The Path Computation Element (PCE) is a core component of Software- Defined Networking (SDN) systems. It can compute optimal paths for traffic across a network and can also update the paths to reflect changes in the network or traffic demands.
PCE was developed to derive paths for MPLS Label Switched Paths (LSPs), which are supplied to the head end of the LSP using the Path Computation Element Communication Protocol (PCEP).
SDN has a broader applicability than signaled MPLS traffic-engineered (TE) networks, and the PCE may be used to determine paths in a range of use cases including static LSPs, segment routing, Service Function Chaining (SFC), and most forms of a routed or switched network. It is, therefore, reasonable to consider PCEP as a control protocol for use in these environments to allow the PCE to be fully enabled as a central controller.
This document briefly introduces the architecture for PCE as a central controller, examines the motivations and applicability for PCEP as a control protocol in this environment, and introduces the implications for the protocol. A PCE-based central controller can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it.
This document does not describe use cases in detail and does not define protocol extensions: that work is left for other documents.
7. An Architecture of Central Controlled Layer 2 Virtual Private Network (L2VPN)
Publication: IETF Individual Draft
Publication History: 2013-10
Publication URL: https://tools.ietf.org/html/draft-li-l2vpn-ccvpn-arch-00
Description:
With the emergence of Software Defined Networks (SDN), the architecture of forwarding and control element separation will develop faster. In the central controlled framework, control functionality of L2VPN can be done only by the Controllers. Consequently it can reduce control functionality in network nodes. This document defines the architecture of central controlled L2VPN and corresponding protocol extension requirement.
8. Inter-SDN (SDNi) in Seamless MPLS for Mobile Backhaul Network
Publication: IETF Individual Draft
Publication History: 2017-03
Publication URL: https://tools.ietf.org/html/draft-li-rtgwg-sdni-seamless-mpls-mbh-00
Description:
This document introduces the inter-SDN framework of Seamless MPLS to integrate the mobile backhaul network with the core network.
9. Hierarchy of IP Controllers (HIC)
Publication: IETF Individual Draft
Publication History: 2020-03
Publication URL: https://tools.ietf.org/html/draft-li-teas-hierarchy-ip-controllers-04
Description:
This document describes the interactions between various IP controllers in a hierarchical fashion to provide various IP services. It describes how the Abstraction and Control of Traffic Engineered Networks (ACTN) framework is applied to the Hierarchy of IP controllers (HIC) as well as document the interactions with other protocols like BGP, Path Computation Element Communication Protocol (PCEP) to provide end to end dynamic services spanning multiple domains and controllers (e.g. Layer 3 Virtual Private Network (L3VPN), Seamless MPLS etc).
Central Management
1. Requirements and Architecture of Carrier IP Service Models
Publication: IETF Individual Draft
Publication History: 2017-03
Publication URL: https://tools.ietf.org/html/draft-li-opsawg-carrier-ip-service-model-req-arch-01
Description:
Service Model is a fundamental building block for a controller’s North-Bound Interface (NBI). Defining a service model for different multi-layered and heterogeneous networks is a complicated work and may require lots of consideration since different model users may have different perspective and concerns.
This document proposes the requirements and architecture for service models to facilitate future work. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks, requirements, architecture and guidelines from which models may be constructed.
2. Considerations on Layered Network VPN Service Model
Publication: IETF Individual Draft
Publication History: 2015-10
Publication URL: https://tools.ietf.org/html/draft-zhuang-opsawg-netvpn-model-considerations-00
Description:
VPN is one typical service provided by carrier IP network. Network VPN service model can provide the northbound interface of network- level VPN service of the controller to try to simplify the VPN provision without involving too much details of VPN implementation on the device. This document gives exploratory description about the requirement of network-level VPN service and how to define the data model which will provide the guidance for the future definition of the concrete data model.
3. Yang Model of Network-based P2P TE Tunnel
Publication: IETF Individual Draft
Publication History: 2017-03
Publication URL: https://tools.ietf.org/html/draft-jiang-opsawg-nettunnel-model-yang-00
Description:
This document defines a YANG data model for network-based P2P TE Tunnel which can be abstracted and exposed as north bound API of SDN Controller.
4. An Architecture of Instant VPN
Publication: IETF Individual Draft
Publication History: 2013-10
Publication URL: https://tools.ietf.org/html/draft-li-l3vpn-instant-vpn-arch-00
Description:
With the wide application of cloud computing technology, more and more enterprises will hire public cloud data center resources, reduce their own costs. Providers need to enterprise data center rental network and enterprise own network connected together, provide enterprise lease line services. L3VPN is most providers provide this service selection. New VPN line business needs to rapidly deploy, but the current technology cannot meet this requirement. This document introduces the architecture to deploy L3VPN rapidly which can satisfy the requirement for service provision.
5. Summary of I2RS Use Case Requirements
Publication: IETF Individual Draft
Publication History: 2016-11
Publication URL: https://tools.ietf.org/html/draft-ietf-i2rs-usecase-reqs-summary-03
Description:
The I2RS Working Group (WG) has described a set of use cases that the I2RS systems could fulfil. This document summarizes these use cases. It is designed to provide requirements that will aid the design of the I2RS architecture, Information Models, Data Models, Security, and protocols.