Internet DRAFT - draft-rfernando-ipse
draft-rfernando-ipse
INTERNET-DRAFT Rex Fernando
Intended Status: Standard Track Sami Boutros
Dhananjaya Rao
Cisco Systems
Nabil Bitar
Luay Jalil
Verizon
Expires: January 7, 2016 July 6, 2015
Interface to a Packet Switching Element (IPSE)
draft-rfernando-ipse-02.txt
Abstract
This document describes a set of mechanisms for decoupling the
control and data plane of a routing or a switching device and
describes an open API between the two that satisfies a set of
constraints that are desirable for such an interface.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Fernando Expires January 7, 2016 [Page 1]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Routing and Switching Systems Model . . . . . . . . . . . . . . 4
2.1 Control Plane (Route Controller) . . . . . . . . . . . . . . 5
2.2 Forwarding Plane (Packet Switching Element) . . . . . . . . 5
2.3 Motivation for separation of Route Controller and Packet
Switching Elements(s) . . . . . . . . . . . . . . . . . . . 5
2.4 Different constructions of RC and PSE(s) . . . . . . . . . . 7
3. Packet Switching Element Conceptual Model . . . . . . . . . . . 8
3.1 Typical PSE model . . . . . . . . . . . . . . . . . . . . . 8
3.1.1 I/P Block (Input Processing) . . . . . . . . . . . . . . 8
3.1.2 O/P Block (Output Processing) . . . . . . . . . . . . . 9
3.1.3 Forwarding Block . . . . . . . . . . . . . . . . . . . . 9
3.1.3.1 Forwarding block model . . . . . . . . . . . . . . . 9
3.1.3.2 Context Selection Block . . . . . . . . . . . . . . 10
4. Yang modules . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1 YANG Module "pse" . . . . . . . . . . . . . . . . . . . . . 11
4.2 YANG Module "pse-common-types" . . . . . . . . . . . . . . . 16
4.3 Global sub-modules of "pse" . . . . . . . . . . . . . . . . 17
4.3.1 YANG sub module "pse-oam" . . . . . . . . . . . . . . . 17
4.3.2 YANG submodule "physical-interfaces" . . . . . . . . . . 19
4.3.3 YANG submodule "context-selector-table" . . . . . . . . 20
4.3.4 YANG submodule "label-table" . . . . . . . . . . . . . . 22
4.3.5 YANG submodule "l2tp-table" . . . . . . . . . . . . . . 26
4.4 PER Tenant submodules . . . . . . . . . . . . . . . . . . . 27
4.4.1 YANG submodule "ip-unicast-table" . . . . . . . . . . . 27
4.4.2 YANG submodule "flow-table" . . . . . . . . . . . . . . 30
4.4.3 YANG module "ip-next-hop" . . . . . . . . . . . . . . . 30
4.4.4 YANG submodule "l2-table" . . . . . . . . . . . . . . . 32
4.4.5 YANG submodule "l2-next-hop" . . . . . . . . . . . . . . 33
4.4.6 YANG submodule "interface-table" . . . . . . . . . . . . 36
Fernando Expires January 7, 2016 [Page 2]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
4.4.7 YANG submodule "arp-table" . . . . . . . . . . . . . . . 39
4.4.8 Yang submodule "arp-proxy-table" . . . . . . . . . . . . 40
5 Performance and scale requirements . . . . . . . . . . . . . . . 41
6 YANG data model tree . . . . . . . . . . . . . . . . . . . . . . 42
7 Major Contributing Authors . . . . . . . . . . . . . . . . . . . 47
8 Security Considerations . . . . . . . . . . . . . . . . . . . . 47
9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 47
10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
10.1 Normative References . . . . . . . . . . . . . . . . . . . 47
10.2 Informative References . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47
Fernando Expires January 7, 2016 [Page 3]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
1 Introduction
This document describes a data model driven API to program a routing
and switching system's forwarding plane. It describes the motivations
for creating an open API between a router's control and its
forwarding plane and lays out the exact mechanisms that can be used
by the control plane of a routing system to "program" the forwarding
tables and state contained in the forwarding plane and additionally
get notifications when that state changes in interesting ways. It
also describes APIs to extract information from the forwarding plane,
such as queue statistics.
The document proposes YANG as the modeling language for this purpose
and provides the exact models that represent the forwarding state of
a routers data plane.
YANG provides Hierarchical data models and modularity through the use
of modules and submodules, that we can use to express the forwarding
tables, forwarding objects and adjacencies. The ease of extending the
data model through augmentation mechanisms and the versioning rules
supported by YANG would allow us to easily extend the model with new
forwarding features.
The use of YANG would allow us to decouple the data model from the
encoding method and the transport protocol. The encoder/decoder for
YANG is agnostic of the forwarding data model specifics.
Netconf has been used as the transport protocol for YANG, and Netconf
is a socket based reliable transport protocol that defines as well
security and authentication semantics for the communication of the
YANG data model if required.
Note that this document uses the word "router" to refer to any
network packet forwarding device. The mechanisms outlined here are
equally applicable to L3 devices (routers), L2 devices (switches),
MPLS label switches and any device that's a hybrid.
1.1 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 RFC 2119 [RFC2119].
2. Routing and Switching Systems Model
Fernando Expires January 7, 2016 [Page 4]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
Most modern routing and switching systems have two main components:
the control plane and the data plane. Traditionally these systems
implement proprietary closed communication between the control and
the data plane.
2.1 Control Plane (Route Controller)
The control plane typically implements different functions on a
routing and switching system, which include open interfaces for
external management and orchestration, an interface to retrieve
operational data, routing and switching control protocols to interact
with other network elements or hosts, route computation and database
to store computed results (RIB) and internal event handling
infrastructure that glues these control components together.
The rest of the document will refer to the control plane as the
"route controller" or just RC.
2.2 Forwarding Plane (Packet Switching Element)
The forwarding plane performs the forwarding functions on packets
received on physical interfaces as per the control directives and
state added by the control plane. It also informs the control plane
of local events and various operational state so that the control
plane can take the necessary actions.
The rest of this document will refer to the forwarding plane as the
"packet switching element" or just PSE.
The PSE has the following functional modules:
1. An PSE control agent that interfaces with the control plane. The
agent supports the protocol that is used to communicate with the
route controller. It processes the forwarding table and interface
updates sent by the controller and populates the forwarding tables
policy rules and associated actions that the packet processing logic
needs. It also reports events and statistics to the route controller
2. Packet processing module that performs the actual packet
forwarding and packet manipulation actions. It has a set of
forwarding and interface tables that it uses to lookup both runtime
and configuration state. The packet processing module also collects
various statistics and error counters, as well as generates events.
2.3 Motivation for separation of Route Controller and Packet Switching
Elements(s)
Fernando Expires January 7, 2016 [Page 5]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
The advent of software defined networking (SDN) and virtualization
have opened up many well understood reasons for creating an open
interface between the route controller (RC) and forwarding element
(PSE). The reasons include but not limited to such factors as, (a)
being able to run the route controller on commodity x86 servers and
still be able to control the data plane of legacy devices, (b) being
able to create interesting routing and bridging topologies and
realizing policies at the forwarding plane, (c) modularizing the
interface allows best in class products to be assembled without a
vendor "lock-in" and the innovation that such a model provides and
(d) the cost savings provided by the de-coupled model where a central
control plane can provide better control and efficiency in directing
packet flows than the traditional distributed protocol based control
plane and (e) the ability to scale out the control plane
independently from the forwarding plane, maximizing resource
utilization. Specifically, a control plane can scale out to control a
large number of forwarding modules that are part of the same routing
system while maximizing the utilization of the forwarding modules'
hardware resources
In short the benefits of software driven networking can be
effectively realized by decoupling the route controller and packet
switching elements and providing an open interface between the two.
An important consideration in providing this modularity is the
'reuse' of technology concepts instead of reinventing a brand new
mechanism at the data plane level just to provide an open interface.
There are many downsides to creating a new data plane model than the
well understood 'IP routing' or 'L2 switching' models - the foremost
of them being that existing equipment where the hardware behavior is
'baked' in have to be forklift upgraded and replaced with devices
that support the new forwarding model. Even if one were to ignore the
impracticality of such a solution, one cannot ignore the investment
loss in rendering all the legacy devices useless. Let alone that it
might toe the innovation in implementations. There is need to
abstract the actual forwarding model implementation from the control
applications that can manipulate the behavior of the forwarding plane
or extract information from it.
A more practical approach to solving the control and data plane
separation is to provide an interface to these devices that use
existing data plane concepts and objects such as IP prefixes, L2 mac
entries, next-hops (direct and recursive), vlans, MPLS labels, tunnel
encapsulations, interfaces/ports, ECMP forwarding and VRF, EVI and
VSI containers, and policies and associated actions. Hence, IPSE
expresses the forwarding data model as a chain of forwarding objects,
and allowing updates to any object at any level of the chain.
Fernando Expires January 7, 2016 [Page 6]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
Most devices understand these concepts and objects and use these
concepts and objects to classify and forward data traffic. The idea
behind IPSE is to create an abstraction layer to these forwarding
objects that allows an external control plane to communicate with a
forwarding plane to program these objects. The packet switching
element (PSE) itself could be both hardware or software based.
Software based PSE's are increasingly becoming popular especially in
data center and cloud use cases where multi-tenanted topologies can
be rapidly created by installing a software switch/router in the
server hosting the cloud and data center applications and using a
central controller to program their forwarding tables [VPE DRAFT].
2.4 Different constructions of RC and PSE(s)
While the RC and PSEs can be separated from a communication
perspective as outlined in the previous section, there are two
distinct ways they can be packaged to work with each other.
The more traditional packaging involves both these functions co-
located in a single device (for instance within a router chassis).
The de-coupling of the controller and PSE enables them to be
separated out with the RC running in a different device than the PSE.
This might be desirable, because, the controller as an application
has different functional, performance and scale characteristics that
it would be inefficient and suboptimal for it to be coupled with the
forwarding elements.
One of the benefits of the model based approach to the separation of
RC and PSE is that, as long as the PSE(s) implements the models
described in this document and can have a back-end that can honor the
semantics of the models defined here, the PSE could be either
software based or hardware based. In addition, how the model
translates into implementation is abstracted away.
This allows for integration of not just software based forwarding
elements but can also include hardware forwarding elements (legacy
router forwarding plane) as long as the forwarding plane abstraction
layer implements the YANG models defined in this document. <The
specific hardware mechanisms used to implement the models may vary
depending on the device.>
Lastly, when it comes to routing and reachability, the approach we
take to scale the system is to treat the RC and PSE(s) as have been
viewed traditionally. IOW, a set of PSE(s) can be programmed by a RC.
An RC could be cluster of two or servers, each server containing one
or more CPU, associated memory, storage and network interfaces. A
Fernando Expires January 7, 2016 [Page 7]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
routing system will be composed of an RC (and optionally a redundant
RC) and a set of PSEs. Two such routing systems would then talk to
each other using traditional routing and signaling protocols as
needed, and to hosts or host proxies using traditional protocols
(e.g., DHCP). On the opposite, the proposed architecture is targeted
to better enable scalability by breaking the traditional topology
where the RC is boxed in with the a set of PSEs in the same chassis.
This alignment to an existing routing model also allows one to keep
certain operational aspects intact with respect to the RC/PSE
construction. When properly built, the fact that RC and PSE(s) are
de-coupled may not be exposed to operational systems if needed.
3. Packet Switching Element Conceptual Model
This section describes in brief the conceptual model for the packet
switching element (PSE). It describes the various functional blocks
and typical forwarding chains that a packet may pass through within
the PSE. The various tables specified in the data model in the
subsequent section contain the state needed to carry out the packet
processing described here.
3.1 Typical PSE model
In the packet forwarding path, an PSE consists of the following high-
level logical blocks.
+------------+ +-----------+ +------------+
In-Phy->| I/P Block |-+->|Forwarding |-+->| O/P Block |->Out-Phy
|(ACL,QoS,..)| | +-----------+ | |(ACL,QoS,..)|
+------------+ | | +------------+
+ ---<---<---<---v
In-Phy: A Physical interface via which packets are received by the
device.
Out-Phy:A physical interface via which packets are transmitted out of
the device.
3.1.1 I/P Block (Input Processing)
This is a logical packet processing block at the input to a routing
or switching device. This block acts upon the packet based on the
interface properties and ingress policing rules and packet
attributes. It also generates the necessary inputs to the forwarding
block.
A device contains two broad categories of interfaces - those facing
Fernando Expires January 7, 2016 [Page 8]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
the edge or providing access to an edge network or device, and those
facing the core network. The input (and output) processing logic
applies to both categories, though the rules and actions performed
might be different.
3.1.2 O/P Block (Output Processing)
This is a logical packet processing block at the output stage of
packet forwarding. This block typically applies the output features
such as output port policing, queuing and filtering before
transmitting the packet out on the physical port.
3.1.3 Forwarding Block
This is the block that contains the various forwarding and adjacency
tables, and the logic that does the forwarding table lookups and
packet rewrites. This document focuses on the models required to
describe the behavior and state required by the forwarding block.
Depending on the type of an incoming packet, it is possible to do
forwarding based on different attributes or combinations of
attributes in the packet header. Each of these attributes can be
considered as a forwarding class, and a given packet may be subject
to multiple of them, based on user requirements.
The forwarding-class selector logic identifies the fields in the
packet header that will be used to do the lookup for each forwarding-
class supported on the device. The lookup occurs in a specific table
for that class.
There is a logically separate FIB table for each class. Additionally,
a device may support multiple logical instances of each table, for
example, an IP FIB per VRF.
3.1.3.1 Forwarding block model
+------------------------------+
| |
| Route Lookup, |
+-----------+ | Next-Hop Selection & |
---+-->| Context |--->| Packet Rewrite |-------+--->
|(A)| Selection |(B) | +-------++-------++-------+ | (C) |
| +-----------+ | |Context||Context||Context| | |
| | |global ||'pepsi'||'coke' | | |
| | | || || | | |
^ | |L2,L3, ||L2,L3 ||L2,L3 | | |
| | |Tables ||Tables ||Tables | | |
| | +-------++-------++-------+ | |
| +------------------------------+ |
Fernando Expires January 7, 2016 [Page 9]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
| (Recirculation) |
+-----<---------<---------<---------<---------<---------<---+
Forwarding Block
Conceptually, there are two components to the forwarding block. The
context selection logic and the actual route lookup, next-hop
selection and packet rewrite block. The idea is that an incoming
packet can be processed completely by these two blocks and then sent
out on an output port towards its next-hop. In some cases, however,
it might be easier to construct more complex scenarios by
recirculating the packet multiple times through these two blocks.
For instance, when an MPLS-VPN packet is received in the core facing
interface, the packet is encaped with the VPN label. The VPN label is
looked up in the global label table, the result of the lookup could
point to the final next-hop or to the context ip table in which the
ip packet destination should be looked up in to find the final next-
hop. It is easier to construct this 'chained' operation by simply
recirculating the packet through the 'context selector' and 'route
lookup' blocks than constructing a specific chain for this particular
scenario.
The idea then is to generalize the forwarding actions by decomposing
them into a series of 'context selection' followed by 'route lookup'
operations than creating static chain of such operations on a per
scenario basis.
3.1.3.2 Context Selection Block
The context-selector block determines the specific forwarding context
and the specific table within that context in which to perform the
forwarding lookup for an incoming packet. A device may have multiple
forwarding contexts to support multi-tenancy. Each forwarding context
could have multiple tables to support different types of lookups (L2,
IPv4, IPv6, flow, etc).
Inputs to the context selection is the received packet itself
together with information on the input interface (physical or
logical) on which the packet was received.
Currently the model supports determination of the context and table
based on the switching mode set on the interface or based on the
table pointed to by the MPLS VPN label on the packet.
The output of the context selection block is the {context, table}
Fernando Expires January 7, 2016 [Page 10]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
pair to perform the lookup on. The output table could be L2, IPv4 or
IPv6 based on the packet type and the mode set on the input interface
or as implied by the VPN label on the packet.
4. Yang modules
In this section we describe the different YANG modules implementing
the data model for the Packet Switching Elements (PSEs). The
following sections will define a hierarchy of tables that are needed
to implement the L2, L3, MPLS and flow forwarding functions.
As is evident, there are cases where the forwarding lookup has to be
scoped by a given 'tenant'. In other cases the lookup has to be
performed at a global level.
At the top level we will define tables that have global scope i.e.
not per tenant. The following are the tables that have global scope,
a. The interface table that describe the interfaces attached to the
PSE's.
b. The Context Selector table that tells the PSE how to map traffic
arriving on a physical or logical interface to the tenant L2, L3 or
flow forwarding tables. The output of the context selector table is a
tenant context and a table name within that context to perform a
lookup on.
c. The MPLS label table that lists all the MPLS labels and the
associated tenant L2, L3 of flow forwarding tables
d. The L2 tunnel table that will list all the tenants L2 tunnels for
point2point cross-connects
e. The OAM table that lists the logical or physical interfaces as
well as the end-point prefixes that need to be monitored by the
forwarding element. The interface state is monitored through local
events such as 'link up' and 'link down'. Prefixes are monitored
through OAM protocols such as ICMP or BFD. A change in state of
interfaces or prefix reachability could trigger notification to the
route controller to ensure service assurance and continuity.
Then we will be defining the per tenant forwarding table hierarchy,
in which we will define both L2, L3 and flow forwarding tables and
the corresponding L2 and L3 next-hops.
4.1 YANG Module "pse"
The Packet Switching Element (PSE) module is the top level module
Fernando Expires January 7, 2016 [Page 11]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
that allows for provisioning and managing a set of global tables and
tenant specific tables. The module defines read-only variables that
allows the route controller to query for PSE's forwarding
capabilities and features that are supported by the PSE that can be
turned on or utilized by the RC.
It allows for provisioning for IPv4, IPv6, L2, MPLS Label & Flow
forwarding tables based on device capabilities.
As the top level table, it includes other tables (such as interface
table, arp table, L3 and L2 tables) that are needed to perform packet
forwarding.
module pse {
namespace "http://www.cisco.com/yang-modules/ipse/pse";
prefix "pset";
import ietf-inet-types {
prefix "inet";
}
import pse-common-types {
prefix "ct";
}
include interface-table;
include context-selector-table;
include arp-table;
include arp-proxy-table;
include l2tp-table;
include pse-oam;
include ip-unicast-table;
include l2-table;
include flow-table;
include label-table;
description "PSE stands for Packet Switching Element.
The module allows for provisioning and managing
multi-tenant forwarding tables in a network device.
Currently supports IPv4, IPv6, L2 & Flow forwarding
entries based on device capabilities. This module will be
extended to support multicast in future";
organization "Cisco Systems";
contact "employee@cisco.com";
revision 2013-12-05 {
description "Initial revision.";
Fernando Expires January 7, 2016 [Page 12]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
}
container pse-global-features {
description "PSE capabilities and features (read only)";
config false;
leaf ready {
description "Once the controller connects to the pse
it can be notified (or it can query) about the pse
state to check if pse is READY";
type boolean;
}
leaf ip-unicast-forwarding {
description "This feature indicates that the device
implements IPv4 based unicast forwarding";
type boolean;
}
leaf l2-forwarding {
description "This feature indicates that the device
implements forwarding based on L2 addresses";
type boolean;
}
leaf flow-forwarding {
description "This feature indicates that the device
implements flow forwarding based on (src-ip, dst-ip,
src-port, dst-port, protocol)";
type boolean;
}
uses ip-unicast-features;
uses l2-features;
uses flow-features;
}
container pse-oam {
description "This global table can be used to determine
the health status of objects - such as interface state
and reachability of a prefix";
Fernando Expires January 7, 2016 [Page 13]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
uses pse-oam;
}
container sync {
leaf sync-state {
description "Used to Synchronize PSE tables. These
variables could be used by the route controller to
indicate the start and end of a route download
operation";
type enumeration {
enum sync-start;
enum sync-complete;
}
}
}
container context-selector-table {
uses context-selector-table;
}
uses label-table;
container interface-table {
uses if-table;
}
container protocol-addresses {
container ipv4 {
container table {
uses ct:table-name;
}
leaf source-address {
type inet:ipv4-address;
}
leaf dhcp-address {
type inet:ipv4-address;
}
leaf gateway-address {
type inet:ipv4-address;
}
}
container ipv6 {
container table {
uses ct:table-name;
}
Fernando Expires January 7, 2016 [Page 14]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
leaf source-address {
type inet:ipv6-address;
}
leaf dhcp-address {
type inet:ipv6-address;
}
leaf gateway-address {
type inet:ipv6-address;
}
}
}
uses l2tp-table;
list pse-contexts {
description "This list represents a provisioned list of
packet forwarding contexts. Each context could represent
a distinct tenant and network address space. Forwarding
tables and other policy parameters related to routing,
addressing, forwarding are assumed to be defined within
a pse context. Each pse context is uniquely identified by
a name";
key pse-context-name;
leaf pse-context-name {
type string;
}
list tables {
description
"list of forwarding tables within the context,
indexed by unique table's name ";
key table-name;
leaf table-name {
type string;
description "Instance of a forwarding table
identified by name";
}
leaf pse-vpn-id {
type string;
description "VPN-ID used by DHCP";
}
Fernando Expires January 7, 2016 [Page 15]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
choice pse-table-type {
case ip-unicast-table {
container arp-table {
uses arp-table;
}
container arp-proxy-table {
uses arp-proxy-table;
}
container ip-unicast-table {
uses ip-unicast-table;
}
}
case l2-table {
container l2-table {
uses l2-table;
}
}
case flow-table {
container flow-table {
uses flow-table;
}
}
}
}
}
}
4.2 YANG Module "pse-common-types"
This module defines some common types used by all the modules and sub
modules defined in this document.
module pse-common-types {
namespace
"http://www.cisco.com/yang-modules/ipse/pse-common-types";
prefix "psect";
revision "2013-12-05" {
description "Initial revision.";
}
grouping table-name {
Fernando Expires January 7, 2016 [Page 16]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
description "The unique table's name is specified by PSE
context-name, and the table's name within the context";
leaf pse-ctx-name {
description "The name of PSE context";
type string;
}
leaf ctx-tbl-name {
description "The name of table within PSE context";
type string;
}
}
typedef interfaceName {
type string;
}
typedef interfaceLogicalUnit {
type int32 {
range "0..9999";
}
}
typedef prefixLengthIPv4 {
type int32 {
range "0..32";
}
}
typedef prefixLengthIPv6 {
type int32 {
range "0..128";
}
}
}
4.3 Global sub-modules of "pse"
4.3.1 YANG sub module "pse-oam"
This sub module defines the provisioned and operational list of
interfaces and prefixes to be monitored by the devices implementing
the PSE.
submodule pse-oam {
belongs-to pse {
Fernando Expires January 7, 2016 [Page 17]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
prefix "pset";
}
import pse-common-types {
prefix "ct";
}
import ietf-inet-types {
prefix "inet";
}
organization "Cisco Systems";
contact "joe@acme.example.com";
description
"OAM Status for PSE ";
revision 2013-12-05 {
description "Initial revision.";
}
grouping pse-oam {
container prefix-table {
list unicast-prefix {
description
"This list defines the prefixes to be monitored by
OAM.";
key "prefix";
leaf prefix {
type inet:ip-prefix;
}
}
}
container interface-table {
list interfaces {
description
"This list defines the interfaces to be monitored by
OAM";
key "interface-name";
leaf interface-name {
type ct:interfaceName;
}
}
}
Fernando Expires January 7, 2016 [Page 18]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
container oper-prefix-down-table {
config false;
list oper-prefix-down-list {
description
"This list defines the prefixes oper down state
monitored by OAM";
key "version";
leaf version {
description "Version ";
type uint32;
}
leaf prefix {
type inet:ip-prefix;
}
}
}
container oper-interface-down-table {
config false;
list oper-interfaces-down-list {
description
"This list defines the interfaces oper down
state monitored by OAM";
key "version";
leaf version {
description "Version ";
type uint32;
}
leaf interface-name {
type ct:interfaceName;
}
}
}
}
}
4.3.2 YANG submodule "physical-interfaces"
This submodule defines the list of physical interfaces discovered on
Fernando Expires January 7, 2016 [Page 19]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
the devices implementing the PSE.
submodule physical-interfaces {
belongs-to pse-tables {
prefix "pset";
}
import pse-common-types {
prefix "ct";
}
organization "Cisco Systems";
contact "employee@cisco.com";
description
"The module list the operational physical interfaces";
revision 2013-12-05 {
description "Initial revision.";
}
grouping physical-interfaces {
container physical-interfaces {
config false;
list interfaces {
description
"This list define the physical interfaces discovered
on end server";
key "interface-name";
leaf interface-name {
type ct:interfaceName;
}
}
}
}
}
4.3.3 YANG submodule "context-selector-table"
This submodule defines the list of per tenant selector types.
submodule context-selector-table {
belongs-to pse-tables {
prefix "pset";
}
Fernando Expires January 7, 2016 [Page 20]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
import pse-common-types {
prefix "ct";
}
organization "Cisco Systems";
contact "joe@acme.example.com";
description
"The module maps incoming traffic to the forwarding table";
revision 2013-12-05 {
description "Initial revision.";
}
typedef tbl-selection-type {
type enumeration {
enum ipv4 {
description "The table for IPv4 traffic is derived
from interface configuration";
}
enum ipv6 {
description "The table for IPv6 traffic is derived
from interface configuration";
}
enum l2-table {
description "The table for L2 lookup is derived
from interface configuration";
}
enum flow-table {
description "The table for flow based forwarding is
derived from interface configuration";
}
}
}
grouping context-selector-table {
container label-ctx-selection-table {
list label-entry {
key label;
leaf label {
type uint32;
}
container disposition-table {
uses ct:table-name;
}
}
}
Fernando Expires January 7, 2016 [Page 21]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
container interface-ctx-selector-table {
list interfaces {
description
" This list define the table selection mechanism
on interface";
key "interface-name selection-type";
leaf interface-name {
type ct:interfaceName;
}
leaf selection-type {
type tbl-selection-type;
}
choice tbl-selection-type {
case ipv4 {
container ipv4-table {
uses ct:table-name;
}
}
case ipv6 {
container ipv6-table {
uses ct:table-name;
}
}
case l2-table {
container ipv6-table {
uses ct:table-name;
}
}
case flow-table {
container ipv6-table {
uses ct:table-name;
}
}
}
}
}
}
}
4.3.4 YANG submodule "label-table"
This submodule defines the list of MPLS labels pointing to the
different per tenant L2 and L3 tables.
submodule label-table {
Fernando Expires January 7, 2016 [Page 22]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
belongs-to pse-tables {
prefix "pset";
}
import ietf-inet-types {
prefix "inet";
}
import ietf-yang-types {
prefix "yang";
}
import pse-common-types {
prefix "ct";
}
organization "Cisco Systems";
contact "joe@acme.example.com";
description
"The module defines a forwarding tables based on IpV4/V6
addresses";
revision 2013-12-05 {
description "Initial revision.";
}
grouping out-label-stats {
leaf packets {
type yang:counter64;
}
leaf bytes {
type yang:counter64;
}
}
grouping mpls-next-hop {
choice ip-next-hop-type {
case ip-nh-type {
description
"Specifies the content of unicast IP next-hop";
leaf ip-next-hop {
type inet:ip-address;
}
leaf interface {
Fernando Expires January 7, 2016 [Page 23]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
type ct:interfaceName;
}
container nh-tbl-name {
uses ct:table-name;
}
}
case ip-nh-type-mpls-gre {
leaf local-gre-addr {
type inet:ip-address;
}
leaf remote-gre-addr {
type inet:ip-address;
}
container nh-gre-tbl-name {
uses ct:table-name;
}
leaf mpls-label {
type uint32;
}
leaf gre-key {
type uint32;
}
}
case ip-nh-type-vxlan {
leaf local-vxlan-addr {
type inet:ip-address;
}
leaf remote-vxlan-addr {
type inet:ip-address;
}
leaf vxlan-id {
type uint32;
}
}
}
leaf label {
description "output label";
type uint32;
}
Fernando Expires January 7, 2016 [Page 24]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
leaf label-type {
type enumeration {
enum valid {
description "valid output label";
}
enum pop {
description "pop-and-forward";
}
}
}
container next-hop-stats {
config false;
uses out-label-stats;
}
}
grouping mpls-nh-array {
list mpls-nh-array {
key next-hop-index;
leaf next-hop-index {
type uint8;
description "The numerical index of next-hop in
next-hop array";
}
leaf nh-weight {
type uint32;
}
uses mpls-next-hop;
}
}
typedef LocalLabelType {
type enumeration {
enum head-prefix {
description "LSP head per-prefix label";
}
enum label-xconnect {
description "Midpoint label";
}
}
}
grouping local-label-attributes {
leaf local-label-type {
type LocalLabelType;
Fernando Expires January 7, 2016 [Page 25]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
description "label type";
}
choice local-label-type-choice {
case head-prefix {
leaf prefix {
type inet:ip-prefix;
}
container pref-table {
uses ct:table-name;
}
}
}
}
grouping label-table {
list label-table {
key "local-label";
leaf local-label {
description "input label";
type uint32;
}
container label-attributes {
uses local-label-attributes;
}
uses mpls-nh-array;
}
}
}
4.3.5 YANG submodule "l2tp-table"
This submodule defines the list of per tenant layer 2 tunnel protocol
(l2tp) point2point cross connects.
submodule l2tp-table {
belongs-to pse-tables {
prefix "pset";
}
import ietf-inet-types {
prefix "inet";
}
Fernando Expires January 7, 2016 [Page 26]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
import pse-common-types {
prefix "ct";
}
organization "Cisco Systems";
contact "joe@acme.example.com";
description
"L2TP v3/v6 tables";
revision 2013-12-05 {
description "Initial revision.";
}
grouping l2tp-table {
list l2tp {
key "src-addr dst-addr session-id";
leaf src-addr {
type inet:ip-address;
}
leaf dst-addr {
type inet:ip-address;
}
leaf session-id {
type uint32;
}
leaf src-cookie {
type uint32;
}
leaf dst-cookie {
type uint32;
}
leaf interface-name {
type ct:interfaceName;
}
}
}
}
4.4 PER Tenant submodules
4.4.1 YANG submodule "ip-unicast-table"
Fernando Expires January 7, 2016 [Page 27]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
This submodule defines the per tenant ipv4/v6 forwarding tables.
submodule ip-unicast-table {
belongs-to pse-tables {
prefix "pset";
}
import ietf-yang-types {
prefix "yang";
}
import iana-afn-safi {
prefix "ianaaf";
}
import ietf-inet-types {
prefix "inet";
}
import ip-next-hop {
prefix "ipnh";
}
organization "Cisco Systems";
contact "joe@acme.example.com";
description
"The module defines a forwarding tables based on IpV4/V6
addresses";
revision 2013-12-05 {
description "Initial revision.";
}
grouping ip-unicast-features {
container ipv4-unicast-features {
description "This feature indicates that the device
implements IPv4 based unicast forwarding";
container ipv4-features {
uses ipnh:ip-next-hop-features;
}
}
container ipv6-unicast-features {
description "This feature indicates that the device
Fernando Expires January 7, 2016 [Page 28]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
implements IPv6 based unicast forwarding";
container ipv6-features {
uses ipnh:ip-next-hop-features;
}
}
}
grouping ip-tbl-attribute {
leaf afi {
description "Type of IP table: ipv4/ipv6";
type ianaaf:address-family;
}
}
grouping prefix-stats {
leaf packets {
type yang:counter64;
}
leaf bytes {
type yang:counter64;
}
}
grouping ip-unicast-table {
container ip-tbl-attrs {
uses ip-tbl-attribute;
}
list unicast-prefix {
key "prefix";
leaf prefix {
type inet:ip-prefix;
}
uses ipnh:ip-nh-array;
container per-prefix-stats {
config false;
uses prefix-stats;
}
}
Fernando Expires January 7, 2016 [Page 29]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
}
}
4.4.2 YANG submodule "flow-table"
This submodule defines the per tenant flow tables to allow for per
flow forwarding across devices implementing the PSE.
TBD.
4.4.3 YANG module "ip-next-hop"
This submodule defines per tenant the list of different L3 next hops
that can be pointed at by L2 and L3 prefixes in the L2 or L3 tables.
module ip-next-hop {
namespace
"http://www.cisco.com/something/something-else/context1";
prefix "ipnh";
import ietf-inet-types {
prefix "inet";
}
import pse-common-types {
prefix "ct";
}
description
"The module defines a set of next-hop tables
specific forwarding tables can be derived";
revision 2013-12-05 {
description "Initial revision.";
}
grouping ip-next-hop-features {
leaf ecmp-supported {
type boolean;
}
leaf ucmp-supported {
type boolean;
}
leaf max-mp-next-hops {
Fernando Expires January 7, 2016 [Page 30]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
type uint32;
}
container nh-type-supported {
leaf nh-type-regular {
type boolean;
}
leaf nh-type-mpls-over-gre {
type boolean;
}
leaf nh-type-vxlan {
type boolean;
}
}
}
grouping ip-next-hop {
choice ip-next-hop-type {
case ip-nh-type {
description
"Specifies the content of unicast IP next-hop";
leaf ip-next-hop {
type inet:ip-address;
}
leaf interface {
type ct:interfaceName;
}
container nh-tbl-name {
uses ct:table-name;
}
}
case ip-nh-type-mpls-gre {
leaf local-gre-addr {
type inet:ip-address;
}
leaf remote-gre-addr {
type inet:ip-address;
}
container nh-gre-tbl-name {
uses ct:table-name;
Fernando Expires January 7, 2016 [Page 31]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
}
leaf mpls-label {
type uint32;
}
leaf gre-key {
type uint32;
}
}
case ip-nh-type-vxlan {
leaf local-vxlan-addr {
type inet:ip-address;
}
leaf remote-vxlan-addr {
type inet:ip-address;
}
leaf vxlan-id {
type uint32;
}
}
}
}
grouping ip-nh-array {
list ip-nh-array {
key next-hop-index;
leaf next-hop-index {
type uint8;
description "The numerical index of next-hop in
next-hop array";
}
leaf nh-weight {
type uint32;
}
uses ip-next-hop;
}
}
}
4.4.4 YANG submodule "l2-table"
This submodule defines the per tenant L2 tables keyed by L2 MAC
Fernando Expires January 7, 2016 [Page 32]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
addresses.
submodule l2-table {
belongs-to pse-tables {
prefix "pset";
}
import ietf-yang-types {
prefix "yang";
}
import l2-next-hop {
prefix "l2nh";
}
organization "Cisco Systems";
contact "joe@acme.example.com";
description
"The module defines a forwarding tables based on L2 MAC
addresses";
revision 2013-12-05 {
description "Initial revision.";
}
grouping l2-features {
uses l2nh:l2-next-hop-features;
}
grouping l2-table {
list L2-table {
key "dst-mac";
leaf dst-mac {
type yang:mac-address;
}
uses l2nh:l2-nh-array;
}
}
}
4.4.5 YANG submodule "l2-next-hop"
This submodule defines per tenant the list of different L2 next hops
that can be pointed at by L2 and L3 prefixes in the L2 or L3 tables.
Fernando Expires January 7, 2016 [Page 33]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
module l2-next-hop {
namespace
"http://www.cisco.com/something/something-else/context3";
prefix "l2nh";
import ietf-inet-types {
prefix "inet";
}
import pse-common-types {
prefix "ct";
}
description
"The module defines a set of next-hop tables
specific forwarding tables can be derived";
revision 2013-12-05 {
description "Initial revision.";
}
grouping l2-next-hop-features {
leaf l2-ecmp-supported {
type boolean;
}
leaf l2-ucmp-supported {
type boolean;
}
leaf l2-max-mp-next-hops {
type uint32;
}
container l2-nh-type-supported {
leaf nh-type-if {
type boolean;
}
leaf nh-type-mpls-over-gre {
type boolean;
}
leaf nh-type-vxlan {
type boolean;
}
}
Fernando Expires January 7, 2016 [Page 34]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
}
grouping l2-next-hop {
choice l2-next-hop-type {
case l2-nh-type-if {
leaf l2-nh-if {
type ct:interfaceName;
}
}
case l2-nh-type-mpls-over-gre {
leaf local-gre-addr {
type inet:ip-address;
}
leaf remote-gre-addr {
type inet:ip-address;
}
leaf gre-key {
type uint32;
}
leaf mpls-label {
type uint32;
}
}
case l2-nh-type-vxlan {
leaf local-vxlan-addr {
type inet:ip-address;
}
leaf remote-vxlan-addr {
type inet:ip-address;
}
leaf vxlan-id {
type uint32;
}
}
}
}
grouping l2-nh-array {
list l2-nh-array {
Fernando Expires January 7, 2016 [Page 35]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
key next-hop-index;
leaf next-hop-index {
type uint8;
description "This is an opaque index generated by the
device to uniquely identify a list of
multi-path next-hops";
}
leaf nh-weight {
type uint32;
}
uses l2-next-hop;
}
}
}
4.4.6 YANG submodule "interface-table"
This submodule defines per tenant table the list of interfaces will
be hosted on a device implementing PSE.
submodule interface-table {
belongs-to pse-tables {
prefix "pse-if";
}
import ietf-interfaces {
prefix if;
}
import ietf-inet-types {
prefix "inet";
}
import pse-common-types {
prefix "ct";
}
description
"Interface table";
organization "Cisco Systems";
contact "employee@cisco.com";
revision 2013-12-05 {
description "Initial revision.";
}
augment "/if:interfaces/if:interface" {
when "if:type = 'ethernetCsmacd' or
Fernando Expires January 7, 2016 [Page 36]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
if:type = 'ieee8023adLag'";
leaf vlan-tagging {
type boolean;
default false;
}
}
augment "/if:interfaces/if:interface" {
when "if:type = 'l2vlan'";
leaf base-interface {
type if:interface-ref;
must "/if:interfaces/if:interface[if:name = current()]"
+ "/if:vlan-tagging = 'true'" {
description
"The base interface must have vlan tagging enabled.";
}
}
leaf outer-vlan-id {
type uint16 {
range "1..4094";
}
must "../base-interface" {
description
"If a vlan-id is defined, a base-interface must
be specified.";
}
}
leaf inner-vlan-id {
type uint16 {
range "1..4094";
}
must "../base-interface" {
description
"If a vlan-id is defined, a base-interface must
be specified.";
}
}
}
augment "/if:interfaces/if:interface" {
when "if:type = 'ethernetCsmacd'";
container ethernet {
must "../if:location" {
description
"An ethernet interface must specify the physical
location of the ethernet hardware.";
}
choice transmission-params {
case auto {
Fernando Expires January 7, 2016 [Page 37]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
leaf auto-negotiate {
type empty;
}
}
case manual {
leaf duplex {
type enumeration {
enum "half";
enum "full";
}
}
leaf speed {
type enumeration {
enum "10Mb";
enum "100Mb";
enum "1Gb";
enum "10Gb";
}
}
}
}
}
}
augment "/if:interfaces/if:interface" {
leaf ip-enabled {
type boolean;
default false;
}
}
augment "/if:interfaces/if:interface" {
leaf base-ip {
type if:interface-ref;
must "/if:interfaces/if:interface[if:name = current()]"
+ "/if:ip-enabled = 'true'" {
description
"The base interface must have vlan tagging enabled.";
}
}
leaf ipv4-addr {
type inet:ipv4-address;
must "../base-interface" {
description
"If an ip address is defined, a base-interface must
be specified.";
}
}
leaf ipv4-prefix-length {
type ct:prefixLengthIPv4;
Fernando Expires January 7, 2016 [Page 38]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
must "../base-interface" {
description
"IPv4 address prefix length";
}
}
leaf ipv6-addr {
type inet:ipv6-address;
must "../base-interface" {
description
"If an ip address is defined, a base-interface must
be specified.";
}
}
leaf ipv6-prefix-length {
type ct:prefixLengthIPv6;
must "../base-interface" {
description
"IPv6 address prefix length";
}
}
leaf mtu {
type uint32;
description
"The size, in octets, of the largest packet that the
interface can send and receive. This node might not be
valid for all interface types.
Media-specific modules must specify any restrictions on
the mtu for their interface type.";
}
leaf unnumbered-to-intf {
type if:interface-ref;
}
}
grouping if-table {
leaf table-int {
type if:interface-ref;
}
}
}
4.4.7 YANG submodule "arp-table"
This submodule defines per tenant the list of ARP entries that will
be hosted on a device implementing PSE.
submodule arp-table {
belongs-to pse-tables {
Fernando Expires January 7, 2016 [Page 39]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
prefix "arp";
}
import ietf-inet-types {
prefix "inet";
}
import ietf-yang-types {
prefix "yang";
}
import pse-common-types {
prefix "ct";
}
organization "Cisco Systems";
contact "joe@acme.example.com";
description
"The module defines a forwarding tables based on IpV4/V6
addresses";
revision 2013-12-05 {
description "Initial revision.";
}
grouping arp-table {
list arptable {
key "ip-address";
leaf ip-address {
type inet:ip-address;
}
leaf mac-address {
type yang:mac-address;
description "Destination MAC Address";
}
leaf interface-name {
type ct:interfaceName;
}
}
}
}
4.4.8 Yang submodule "arp-proxy-table"
This submodule defines per tenant proxy-arp entries that will be
Fernando Expires January 7, 2016 [Page 40]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
hosted on a device implementing PSE.
submodule arp-proxy-table {
belongs-to pse-tables {
prefix "arp-proxy";
}
import ietf-inet-types {
prefix "inet";
}
organization "Cisco Systems";
contact "joe@acme.example.com";
description
"The module defines ARP Proxy tables based on IpV4/V6
addresses";
revision 2013-12-05 {
description "Initial revision.";
}
grouping arp-proxy-table {
list arpproxytable {
key "ip-prefix";
leaf ip-prefix {
type inet:ip-prefix;
}
leaf gateway-ip-address {
type inet:ip-address;
}
}
}
}
5 Performance and scale requirements
Encoding/decoding of forwarding updates must be extremely efficient,
to achieve high performance in terms of number of forwarding
updates/second from control plane to forwarding plane. The transport
protocol must allow for negotiation for different encoding methods.
To achieve high convergence rate of updates, async updates MUST be
used and this can happen by relaxing the dependencies and constraints
between the different modules and objects in the model, leaving the
PSE to resolve the routes forwarding chains via the nexthop and the
different encaps.
Fernando Expires January 7, 2016 [Page 41]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
The details of an efficient encoder/decoder is outside the scope of
this document.
6 YANG data model tree
module: pse-tables
+--ro pse-global-features
| +--ro ready? boolean
| +--ro ip-unicast-forwarding? boolean
| +--ro l2-forwarding? boolean
| +--ro flow-forwarding? boolean
| +--ro ipv4-unicast-features
| | +--ro ipv4-features
| | +--ro ecmp-supported? boolean
| | +--ro ucmp-supported? boolean
| | +--ro max-mp-next-hops? uint32
| | +--ro nh-type-supported
| | +--ro nh-type-regular? boolean
| | +--ro nh-type-mpls-over-gre? boolean
| | +--ro nh-type-vxlan? boolean
| +--ro ipv6-unicast-features
| | +--ro ipv6-features
| | +--ro ecmp-supported? boolean
| | +--ro ucmp-supported? boolean
| | +--ro max-mp-next-hops? uint32
| | +--ro nh-type-supported
| | +--ro nh-type-regular? boolean
| | +--ro nh-type-mpls-over-gre? boolean
| | +--ro nh-type-vxlan? boolean
| +--ro l2-ecmp-supported? boolean
| +--ro l2-ucmp-supported? boolean
| +--ro l2-max-mp-next-hops? uint32
| +--ro l2-nh-type-supported
| | +--ro nh-type-if? boolean
| | +--ro nh-type-mpls-over-gre? boolean
| | +--ro nh-type-vxlan? boolean
| +--ro ecmp-supported? boolean
| +--ro ucmp-supported? boolean
| +--ro max-mp-next-hops? uint32
| +--ro nh-type-supported
| +--ro nh-type-regular? boolean
| +--ro nh-type-mpls-over-gre? boolean
| +--ro nh-type-vxlan? boolean
+--rw pse-oam
| +--rw prefix-table
| | +--rw unicast-prefix [prefix]
| | +--rw prefix inet:ip-prefix
Fernando Expires January 7, 2016 [Page 42]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
| +--rw interface-table
| | +--rw interfaces [interface-name]
| | +--rw interface-name ct:interfaceName
| +--ro oper-prefix-down-table
| | +--ro oper-prefix-down-list [version]
| | +--ro version uint32
| | +--ro prefix? inet:ip-prefix
| +--ro oper-interface-down-table
| +--ro oper-interfaces-down-list [version]
| +--ro version uint32
| +--ro interface-name? ct:interfaceName
+--rw sync
| +--rw sync-state? enumeration
+--rw context-selector-table
| +--rw label-ctx-selection-table
| | +--rw label-entry [label]
| | +--rw label uint32
| | +--rw disposition-table
| | +--rw pse-ctx-name? string
| | +--rw ctx-tbl-name? string
| +--rw interface-ctx-selector-table
| +--rw interfaces [interface-name selection-type]
| +--rw interface-name ct:interfaceName
| +--rw selection-type tbl-selection-type
| +--rw (tbl-selection-type)?
| +--:(ipv4)
| | +--rw ipv4-table
| | +--rw pse-ctx-name? string
| | +--rw ctx-tbl-name? string
| +--:(ipv6)
| +--rw ipv6-table
| +--rw pse-ctx-name? string
| +--rw ctx-tbl-name? string
+--rw label-table [local-label]
| +--rw local-label uint32
| +--rw label-attributes
| | +--rw local-label-type? LocalLabelType
| | +--rw (local-label-type-choice)?
| | +--:(head-prefix)
| | +--rw prefix? inet:ip-prefix
| | +--rw pref-table
| | +--rw pse-ctx-name? string
| | +--rw ctx-tbl-name? string
| +--rw mpls-nh-array [next-hop-index]
| +--rw next-hop-index uint8
| +--rw nh-weight? uint32
| +--rw (ip-next-hop-type)?
| | +--:(ip-nh-type)
Fernando Expires January 7, 2016 [Page 43]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
| | | +--rw ip-next-hop? inet:ip-address
| | | +--rw interface? ct:interfaceName
| | | +--rw nh-tbl-name
| | | +--rw pse-ctx-name? string
| | | +--rw ctx-tbl-name? string
| | +--:(ip-nh-type-mpls-gre)
| | | +--rw local-gre-addr? inet:ip-address
| | | +--rw remote-gre-addr? inet:ip-address
| | | +--rw nh-gre-tbl-name
| | | | +--rw pse-ctx-name? string
| | | | +--rw ctx-tbl-name? string
| | | +--rw mpls-label? uint32
| | | +--rw gre-key? uint32
| | +--:(ip-nh-type-vxlan)
| | +--rw local-vxlan-addr? inet:ip-address
| | +--rw remote-vxlan-addr? inet:ip-address
| | +--rw vxlan-id? uint32
| +--rw label? uint32
| +--rw label-type? enumeration
| +--ro next-hop-stats
| +--ro packets? yang:counter64
| +--ro bytes? yang:counter64
+--rw interface-table
| +--rw table-int? if:interface-ref
+--rw protocol-addresses
| +--rw ipv4
| | +--rw table
| | | +--rw pse-ctx-name? string
| | | +--rw ctx-tbl-name? string
| | +--rw source-address? inet:ipv4-address
| | +--rw dhcp-address? inet:ipv4-address
| | +--rw gateway-address? inet:ipv4-address
| +--rw ipv6
| +--rw table
| | +--rw pse-ctx-name? string
| | +--rw ctx-tbl-name? string
| +--rw source-address? inet:ipv6-address
| +--rw dhcp-address? inet:ipv6-address
| +--rw gateway-address? inet:ipv6-address
+--rw l2tp [src-addr dst-addr session-id]
| +--rw src-addr inet:ip-address
| +--rw dst-addr inet:ip-address
| +--rw session-id uint32
| +--rw src-cookie? uint32
| +--rw dst-cookie? uint32
| +--rw interface-name? ct:interfaceName
+--rw pse-contexts [pse-context-name]
+--rw pse-context-name string
Fernando Expires January 7, 2016 [Page 44]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
+--rw tables [table-name]
+--rw table-name string
+--rw pse-vpn-id? string
+--rw (pse-table-type)?
+--:(ip-unicast-table)
| +--rw arp-table
| | +--rw arptable [ip-address]
| | +--rw ip-address inet:ip-address
| | +--rw mac-address? yang:mac-address
| | +--rw interface-name? ct:interfaceName
| +--rw arp-proxy-table
| | +--rw arpproxytable [ip-prefix]
| | +--rw ip-prefix inet:ip-prefix
| | +--rw gateway-ip-address? inet:ip-address
| +--rw ip-unicast-table
| +--rw ip-tbl-attrs
| | +--rw afi? ianaaf:address-family
| +--rw unicast-prefix [prefix]
| +--rw prefix inet:ip-prefix
| +--rw ip-nh-array [next-hop-index]
| | +--rw next-hop-index uint8
| | +--rw nh-weight? uint32
| | +--rw (ip-next-hop-type)?
| | +--:(ip-nh-type)
| | | +--rw ip-next-hop? inet:ip-address
| | | +--rw interface? ct:interfaceName
| | | +--rw nh-tbl-name
| | | +--rw pse-ctx-name? string
| | | +--rw ctx-tbl-name? string
| | +--:(ip-nh-type-mpls-gre)
| | | +--rw local-gre-addr? inet:ip-address
| | | +--rw remote-gre-addr? inet:ip-address
| | | +--rw nh-gre-tbl-name
| | | | +--rw pse-ctx-name? string
| | | | +--rw ctx-tbl-name? string
| | | +--rw mpls-label? uint32
| | | +--rw gre-key? uint32
| | +--:(ip-nh-type-vxlan)
| | +--rw local-vxlan-addr? inet:ip-address
| | +--rw remote-vxlan-addr?inet:ip-address
| | +--rw vxlan-id? uint32
| +--ro per-prefix-stats
| +--ro packets? yang:counter64
| +--ro bytes? yang:counter64
+--:(l2-table)
| +--rw l2-table
| +--rw L2-table [dst-mac]
| +--rw dst-mac yang:mac-address
Fernando Expires January 7, 2016 [Page 45]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
| +--rw l2-nh-array [next-hop-index]
| +--rw next-hop-index uint8
| +--rw nh-weight? uint32
| +--rw (l2-next-hop-type)?
| +--:(l2-nh-type-if)
| | +--rw l2-nh-if? ct:interfaceName
| +--:(l2-nh-type-mpls-over-gre)
| | +--rw local-gre-addr? inet:ip-address
| | +--rw remote-gre-addr? inet:ip-address
| | +--rw gre-key? uint32
| | +--rw mpls-label? uint32
| +--:(l2-nh-type-vxlan)
| +--rw local-vxlan-addr? inet:ip-address
| +--rw remote-vxlan-addr?inet:ip-address
| +--rw vxlan-id? uint32
+--:(flow-table)
+--rw flow-table
+--rw afi? ianaaf:address-family
+--rw flow-table
+--rw src-address inet:ip-address
+--rw dst-address inet:ip-address
+--rw src-port uint32
+--rw dst-port uint32
+--rw protocol-type string
+--rw nh-array
+--rw ip-nh-array [next-hop-index]
+--rw next-hop-index uint8
+--rw nh-weight? uint32
+--rw (ip-next-hop-type)?
+--:(ip-nh-type)
| +--rw ip-next-hop? inet:ip-address
| +--rw interface? ct:interfaceName
| +--rw nh-tbl-name
| +--rw pse-ctx-name? string
| +--rw ctx-tbl-name? string
+--:(ip-nh-type-mpls-gre)
| +--rw local-gre-addr?inet:ip-address
| +--rw remote-gre-addr? inet:ip-address
| +--rw nh-gre-tbl-name
| | +--rw pse-ctx-name? string
| | +--rw ctx-tbl-name? string
| +--rw mpls-label? uint32
| +--rw gre-key? uint32
+--:(ip-nh-type-vxlan)
+--rw local-vxlan-addr? inet:ip-address
+--rw remote-vxlan-addr? inet:ip-address
+--rw vxlan-id? uint32
Fernando Expires January 7, 2016 [Page 46]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
7 Major Contributing Authors
The editors would like to thank Reshad Rahman, Yuri Tsier, and Kausik
Majumdar who made a major contribution to the development of this
document.
Reshad Rahman
Cisco
Email: rrahman@cisco.com
Yuri Tsier
Cisco
Email: ytsier@cisco.com
Kausik Majumdar
Cisco
Email: kmajumda@cisco.com
8 Security Considerations
This document does not introduce any additional security constraints.
9 IANA Considerations
TBD
10 References
10.1 Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2 Informative References
Authors' Addresses
Rex Fernando
Cisco
Email: rex@cisco.com
Sami Boutros
Cisco
Email: sboutros@cisco.com
Fernando Expires January 7, 2016 [Page 47]
INTERNET DRAFT Interface to a Packet Switching Element July 6, 2015
Dhananjaya Rao
Cisco
Email: dhrao@cisco.com
Nabil Bitar
Verizon
Email:nabil.n.bitar@verizon.com
Luay Jalil
Verizon
Email:luay.jalil@verizon.com
Fernando Expires January 7, 2016 [Page 48]
