INTERNET-DRAFT Rex Fernando
Intended Status: Standard Track Sami Boutros
Dhananjaya Rao
Cisco Systems
Expires: October 1, 2014 March 30, 2014
Interface to a Packet Switching Element (IPSE)
draft-rfernando-ipse-00.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 October 1, 2014 [Page 1]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Routing and Switching Systems Model . . . . . . . . . . . . . . 4
2.1 Control Plane (Route Controller) . . . . . . . . . . . . . . 4
2.2 Forwarding Plane (Packet Switching Element) . . . . . . . . 4
2.3 Motivation for separation of Route Controller and Packet
Switching Elements(s) . . . . . . . . . . . . . . . . . . . 5
2.4 Different constructions of RC and PSE(s) . . . . . . . . . . 6
3. Packet Switching Element Conceptual Model . . . . . . . . . . . 7
3.1 Typical PSE model . . . . . . . . . . . . . . . . . . . . . 7
3.1.1 I/P Block (Input Processing) . . . . . . . . . . . . . . 7
3.1.2 O/P Block (Output Processing) . . . . . . . . . . . . . 8
3.1.3 Forwarding Block . . . . . . . . . . . . . . . . . . . . 8
3.1.3.1 Forwarding block model . . . . . . . . . . . . . . . 8
3.1.3.2 Context Selection Block . . . . . . . . . . . . . . 9
4. Yang modules . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1 YANG Module "pse" . . . . . . . . . . . . . . . . . . . . . 11
4.2 YANG Module "pse-common-types" . . . . . . . . . . . . . . . 15
4.3 Global sub-modules of "pse" . . . . . . . . . . . . . . . . 16
4.3.1 YANG sub module "pse-oam" . . . . . . . . . . . . . . . 16
4.3.2 YANG submodule "physical-interfaces" . . . . . . . . . . 19
4.3.3 YANG submodule "context-selector-table" . . . . . . . . 19
4.3.4 YANG submodule "label-table" . . . . . . . . . . . . . . 22
4.3.5 YANG submodule "l2tp-table" . . . . . . . . . . . . . . 25
4.4 PER Tenant submodules . . . . . . . . . . . . . . . . . . . 27
4.4.1 YANG submodule "ip-unicast-table" . . . . . . . . . . . 27
4.4.2 YANG submodule "flow-table" . . . . . . . . . . . . . . 29
4.4.3 YANG module "ip-next-hop" . . . . . . . . . . . . . . . 29
4.4.4 YANG submodule "l2-table" . . . . . . . . . . . . . . . 31
4.4.5 YANG submodule "l2-next-hop" . . . . . . . . . . . . . . 32
4.4.6 YANG submodule "interface-table" . . . . . . . . . . . . 35
Fernando Expires October 1, 2014 [Page 2]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
4.4.7 YANG submodule "arp-table" . . . . . . . . . . . . . . . 38
4.4.8 Yang submodule "arp-proxy-table" . . . . . . . . . . . . 39
5. YANG data model tree . . . . . . . . . . . . . . . . . . . . . 40
6 Major Contributing Authors . . . . . . . . . . . . . . . . . . . 45
7 Security Considerations . . . . . . . . . . . . . . . . . . . . 45
8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 46
9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 46
9.1 Normative References . . . . . . . . . . . . . . . . . . . 46
9.2 Informative References . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
Fernando Expires October 1, 2014 [Page 3]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
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.
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.
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
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, 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)
Fernando Expires October 1, 2014 [Page 4]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
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
that the packet processing logic needs.
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)
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.
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
Fernando Expires October 1, 2014 [Page 5]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
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.
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 containers.
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.
Fernando Expires October 1, 2014 [Page 6]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
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 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 have a redundant RC to back it up in case of failure. Two
such complexes (with RCs and PSE(s)) would then talk to each other
using traditional routing protocols. From this standpoint, there
should be no impact to the scalability or the distributed nature of
existing routing systems due to the de-coupling of RC's and PSE(s).
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 need not be exposed to operational systems.
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
Fernando Expires October 1, 2014 [Page 7]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
or switching device. This block acts upon the packet based on the
interface properties and packet attributes. It also generates the
necessary inputs to the forwarding block.
A device contains two broad categories of interfaces - those facing
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 focusses 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
Fernando Expires October 1, 2014 [Page 8]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
+------------------------------+
| |
| 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 | | |
| | +-------++-------++-------+ | |
| +------------------------------+ |
| (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
Fernando Expires October 1, 2014 [Page 9]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
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}
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
Fernando Expires October 1, 2014 [Page 10]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
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
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;
Fernando Expires October 1, 2014 [Page 11]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
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 extended to support multicast in
future";
organization "Cisco Systems";
contact "employee@cisco.com";
revision 2013-12-05 {
description "Initial revision.";
}
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;
Fernando Expires October 1, 2014 [Page 12]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
}
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"
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 {
Fernando Expires October 1, 2014 [Page 13]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
type inet:ipv4-address;
}
leaf gateway-address {
type inet:ipv4-address;
}
}
container ipv6 {
container table {
uses ct:table-name;
}
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 {
Fernando Expires October 1, 2014 [Page 14]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
type string;
description "Instance of a forwarding table identified
by name";
}
leaf pse-vpn-id {
type string;
description "VPN-ID used by DHCP";
}
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 {
Fernando Expires October 1, 2014 [Page 15]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
namespace "http://www.cisco.com/yang-modules/ipse/pse-common-types";
prefix "psect";
revision "2013-12-05" {
description "Initial revision.";
}
grouping table-name {
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"
Fernando Expires October 1, 2014 [Page 16]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
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 {
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 {
Fernando Expires October 1, 2014 [Page 17]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
type ct:interfaceName;
}
}
}
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;
}
}
}
}
Fernando Expires October 1, 2014 [Page 18]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
}
4.3.2 YANG submodule "physical-interfaces"
This submodule defines the list of physical interfaces discovered on
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.
Fernando Expires October 1, 2014 [Page 19]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
submodule context-selector-table {
belongs-to pse-tables {
prefix "pset";
}
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;
}
Fernando Expires October 1, 2014 [Page 20]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
container disposition-table {
uses ct:table-name;
}
}
}
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;
}
}
}
}
}
}
}
Fernando Expires October 1, 2014 [Page 21]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
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 {
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
Fernando Expires October 1, 2014 [Page 22]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
"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;
}
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;
}
}
}
Fernando Expires October 1, 2014 [Page 23]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
leaf label {
description "output label";
type uint32;
}
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";
}
}
Fernando Expires October 1, 2014 [Page 24]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
}
grouping local-label-attributes {
leaf local-label-type {
type LocalLabelType;
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";
}
Fernando Expires October 1, 2014 [Page 25]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
import ietf-inet-types {
prefix "inet";
}
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;
}
}
}
}
Fernando Expires October 1, 2014 [Page 26]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
4.4 PER Tenant submodules
4.4.1 YANG submodule "ip-unicast-table"
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;
}
}
Fernando Expires October 1, 2014 [Page 27]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
container ipv6-unicast-features {
description "This feature indicates that the device
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 October 1, 2014 [Page 28]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
}
}
}
}
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;
}
Fernando Expires October 1, 2014 [Page 29]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
leaf max-mp-next-hops {
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 {
Fernando Expires October 1, 2014 [Page 30]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
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;
}
}
}
}
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"
Fernando Expires October 1, 2014 [Page 31]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
This submodule defines the per tenant L2 tables keyed by L2 MAC
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 October 1, 2014 [Page 32]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
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 October 1, 2014 [Page 33]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
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 {
key next-hop-index;
Fernando Expires October 1, 2014 [Page 34]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
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
if:type = 'ieee8023adLag'";
leaf vlan-tagging {
Fernando Expires October 1, 2014 [Page 35]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
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 {
leaf auto-negotiate {
type empty;
Fernando Expires October 1, 2014 [Page 36]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
}
}
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;
must "../base-interface" {
description
Fernando Expires October 1, 2014 [Page 37]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
"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 {
prefix "arp";
}
Fernando Expires October 1, 2014 [Page 38]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
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
hosted on a device implementing PSE.
submodule arp-proxy-table {
belongs-to pse-tables {
Fernando Expires October 1, 2014 [Page 39]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
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. 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
Fernando Expires October 1, 2014 [Page 40]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
| | +--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
| +--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]
Fernando Expires October 1, 2014 [Page 41]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
| +--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)
| | | +--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
Fernando Expires October 1, 2014 [Page 42]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
+--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
+--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
Fernando Expires October 1, 2014 [Page 43]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
| | +--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
| +--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
Fernando Expires October 1, 2014 [Page 44]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
+--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
6 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
7 Security Considerations
Fernando Expires October 1, 2014 [Page 45]
INTERNET DRAFT Interface to a Packet Switching Element March 30, 2014
This document does not introduce any additional security constraints.
8 IANA Considerations
TBD
9 References
9.1 Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2 Informative References
Authors' Addresses
Rex Fernando
Cisco
Email: rex@cisco.com
Sami Boutros
Cisco
Email: sboutros@cisco.com
Dhananjaya Rao
Cisco
Email: dhrao@cisco.com
Fernando Expires October 1, 2014 [Page 46]