MPLS functional requirements in cNIS 3
Abstract
This document is a base of MPLS technology support implementation in cNIS. It’s intended for
developers. Among others it includes:
 detailed specification of MPLS related entities, its attributes and types;
 description of business logic;
 guidelines for GUI.
Revision history
Date
Author
Description
2011-04-13
M. Łabędzki
Object identifiers marked with bold font
2011-03-23
M. Łabędzki
Units and enum values completed
2011-02-08
M. Łabędzki, M.
Lewandowski, A. Rybicki,
D. Mierzwiński
‘Other views’ removed so MPLS layer is no longer dependent
on any other layer.
2011-02-08
V. Bilicki
Comments and minor changes
2011-01-28
T. Krysztofiak, M.Łabędzki Document ready for first comments
2011-01-25
M. Łabędzki
Initial version of the document
Table of Contents
1
Introduction ..................................................................................................................................... 3
2
Entities and their attributes ............................................................................................................ 4
3
4
2.1
MPLS node ............................................................................................................................... 4
2.2
MPLS interface......................................................................................................................... 4
2.3
MPLS link ................................................................................................................................. 5
2.4
MPLS switching rule ................................................................................................................ 5
2.5
MPLS tunnel............................................................................................................................. 6
User stories ...................................................................................................................................... 7
3.1
Entity management ................................................................................................................. 7
3.2
Topology discovery .................................................................................................................. 7
3.3
Topology change notification .................................................................................................. 7
3.4
Tunnels .................................................................................................................................... 7
References ....................................................................................................................................... 8
1 Introduction
2 Entities and their attributes
An ‘MPLS node’ represents a device from MPLS technology point of view. The ‘MPLS node’ has ‘MPLS
interfaces’ and ‘MPLS switching rules’.
Usually devices are connected by links and analogically ‘MPLS nodes’ are connected by ‘MPLS links’.
The ‘MPLS link’ is therefore a kind of extension to other types of links.
The ‘MPLS nodes’ can form a kind of a virtual circuit which is called an ‘MPLS tunnel’.
The ‘MPLS switching rule’ represents a single rule that the ‘MPLS node’ uses when switching data
packets.
Legend:
 bold attributes unambiguously identify the object.
2.1 MPLS node
Attribute name
Type
Values
Constraints, comments
Capabilities
Enum (multichoice)
IPV4, IPV6, IPX,
Indicates what kind of packets that node is
APPLETALK,
able to switch (transport)
ETHERNET, PPP (FOR
POINT TO POINT
LINKS), TOKEN RING,
FDDI, ATM, AND FRAME
RELAY
Interfaces
Collection of
(separate page or tab,
interface references see MPLS interface
entity)
Interfaces that the node has, most often they
will be references to interfaces of IP routers
Switching rules
Collection of
switching rules
(separate page or tab,
see MPLS interface
entity)
Initially only label-to-label mappings
Role
Enum
EDGE, CORE,
EDGE+CORE,
Typically, where this node resides: at the
beginning and/or at the end of a tunnel
Name
Text
Rose.man.poznan.pl
Unique identifier of an MPLS node among
other MPLS nodes
Management IP
address
Text
192.168.1.2
The management IP address used to access
the node through SNMP
Location
Reference to
Location object
GeoLocation string in RFC1876 format
Description
Text (multiline)
Description of this node
2.2 MPLS interface
Attribute name
Type
Values
Constraints, comments
VLAN support
Enum
Tagged, untagged,
dual-mode
Name
Text
ge-0/0/0.60
Unique identifier of an interface among other
interfaces on a particular node
Status
Enum
Up, Down,
Maintenance
Represents current status of the port
Tags
Set of key-value pairs Additional
properties defined
by user
2.3 MPLS link
Attribute name
Type
Values
Constraints, comments
Link ID
Text
neighbouring router
id, address of DR
router interface.
Unique identifier of the link throughout the
domain
Link type
Enum
1: POINT TO POINT,
2: MULTI-ACCESS
Type of the link, point to point or multi-access
Interface A
Reference to MPLS
interface
e.g.
Interface selected from MPLS interfaces
nodex.mydomain.net already existing in the system.
ge-0/0/0.60
Interface B
Reference to MPLS
interface
(as above)
Traffic engineering
metric
4 octets, positive
Metric (administrative-weight) assigned by
network administrator
Maximum bandwidth
4 octets, positive
Current maximum bandwidth that can be used
on this link; bytes per second
Maximum reservable
bandwidth
4 octets, positive
Maximum bandwidth that can be reserved on
this link, may be greater than the current
maximum bandwidth; bytes per second
Interface selected from MPLS interfaces
already existing in the system.
Unreserved bandwidth 4 octets, positive
The amount of bandwidth not yet reserved;
bytes per second
Administrative group
4 octets, positive
4-octet bit mask assigned by the network
administrator. Each set bit corresponds to one
administrative group assigned to the
interface. A link may belong to multiple
groups. By convention, the least significant bit
is referred to as “group 0” and most significant
bit is referred to as “group 31”.
Vlan
Number
Integer
Number representing VLAN that link belongs
to
Resiliency
Enum
None, Protection,
Restoration
Represents resiliency mode for the link. NONE
means that upon a failure, circuit is broken.
PROTECTION mode delegates some network
resources to serve as a backup link. In
RESTORATION mode no precautions are
taken, however in case of failure, the circuit
automatically starts to rebuild.
2.4 MPLS switching rule
Attribute name
Type
Values
Constraints, comments
In label
Number (20bits)
The incoming label number
In interface
Reference
Reference to interface receiving the packet
Out label
Number (20bits)
The outgoing label number
Out interface
Reference
Reference to interface forwarding the packet
Rules used by nodes to label and forward incoming packets.
Ingress nodes will have some rules with input label/interface set to null, indicating beginning of
tunnel. Analogously egress nodes will have some rules with null output label/interfaces, indicating
end of the tunnel.
2.5 MPLS tunnel
Attribute name
Type
Values
Constraints, comments
Name
Text
Description
Text (multline)
Ingress
Reference
MPLS Node
Start point of tunnel
Egress
Reference
MPLS Node
End point of tunnel
Path
List of References
List of MPLS
Nodes
Nodes building the path
If switching rules are constant, full path of a packet is determined from the moment when an ingress
router gives it a label and forwards it through outgoing interface.
For each ingress router there can be as many tunnels as there are different inbound rules in this
router.
3 User stories
3.1 Entity management
For each entity mentioned in section 2 the following operations should be possible: view (see object
details), add (create new instance), edit (modify details), remove (delete particular instance).
3.2 Topology discovery
There should be possibility to collect MPLS information in an automated way directly from network
devices.
Data stored in cNIS should be updated very frequently (every 30 minutes).
If possible, topology info should be collected in real-time (for example using Quagga).
3.3 Topology change notification
Topology changes should be sent to services using cNIS.
3.4 Tunnels
There should be a possibility to deduce tunnels basing on available switching rules. To know more
about deduction method see [1].
4 References
[1] V. Bilicki, “cNIS MPLS-TE Domain Model”,
https://intranet.geant.net/sites/Services/SA2/T5/cNIS/Documents/design/cNIS-MPLSTE%20domain%20model.doc