GFD-R-P.

206 Jeroen van der Ham, UvA (editor)

NML-WG Freek Dijkstra, SURFsara
nml-wg@ogf.org Roman Łapacz, PSNC
Jason Zurawski, Internet2

May 2013

Network Markup Language Base Schema version 1

Status of This Document
Grid Final Draft (GFD), Proposed Recommendation (R-P).

Copyright Notice
Copyright c Open Grid Forum (2008-2013). Some Rights Reserved. Distribution is unlim-
ited.

Abstract
This document describes a set of normative schemas which allow the description of computer
network topologies.

Contents
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Notational Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Diagrammatic Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 NML Base Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1 Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1 Network Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.2 Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.3 Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.4 Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1
GFD-R-P.206 May 2013

2.1.5 Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.6 Switching Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.7 Adaptation Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.8 De-adaptation Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.9 Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.10 Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.11 Port Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.12 Link Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.13 Bidirectional Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.14 Bidirectional Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.15 Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.16 Lifetime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.17 Label . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1.18 Label Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1.19 Ordered List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1.20 List Item . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2 Relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.1 canProvidePort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.2 existsDuring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.3 hasInboundPort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.4 hasLabel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.5 hasLabelGroup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.6 hasLink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.7 hasNode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.8 hasOutboundPort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.9 hasPort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.10 hasService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.11 hasTopology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.12 implementedBy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.13 isAlias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.14 isSerialCompoundLink . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.15 isSink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.16 isSource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.17 item . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2.18 locatedAt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2.19 next . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2.20 providesLink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2.21 providesPort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.3 Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2
GFD-R-P.206 May 2013

2.4 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3 Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.1 Schema Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2 Instance Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.1 Lexical Equivalence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.2 Further Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.3 Interpreting Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.4 Network Object Attribute Change . . . . . . . . . . . . . . . . . . . . . 31
3.3 Unnamed Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1 XML Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2 OWL RDF/XML Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3 Combining Object Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.4 Ordered Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.1 Examples in XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2 Examples in OWL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.3 Conceptual Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.3.1 Topology and Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.3.2 Hierarchical Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.3.3 Links, Segments and Paths . . . . . . . . . . . . . . . . . . . . . . . . 47
5.3.4 Patch Panel and Media Convertor . . . . . . . . . . . . . . . . . . . . . 48
5.3.5 VLAN and Broadcast Medium . . . . . . . . . . . . . . . . . . . . . . . 48
5.3.6 Configuration and Potential Capability . . . . . . . . . . . . . . . . . . 49
5.3.7 Versioning and Lifetime . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6 Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
7 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
8 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
9 Intellectual Property Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
10 Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
11 Full Copyright Notice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Appendix A XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Appendix B OWL Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Appendix C Relation to G.800 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Normative References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Informative References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

3
GFD-R-P.206 May 2013

1 Introduction
This document describes the base schema of the Network Markup Language (NML). Sec-
tion 2.1 defines the NML classes and their attributes and parameters. Section 2.2 describes
the relations defined between NML classes.
An NML network description can be expressed in XML[XML], and RDF/XML[RDF-XML]
syntax. Section A describes the XSD schema for the XML syntax. Section B describes the
OWL 2 schema for the RDF/XML syntax.
These basic classes defined in this document may be extended, or sub-classed, to represent
technology specific classes.
Section 5 provides example use cases. This section is informative. Only sections 2, 3, 4, and
appendices A and B are normative and considered part of the recommendation.
Appendix C is informative and explains the relation between terms defined in this document
and those defined in the ITU-T G.800 recommendation [G.800].

1.1 Context
The Network Markup Language (NML) has been defined in the context of research and
education networks to describe so-called hybrid network topologies. The NML is defined as
an abstract and generic model, so it can be applied for other network topologies as well. See
[GFD.165] for an detailed overview including prior work.

1.2 Scope
The Network Markup Language is designed to create a functional description of multi-
layer networks and multi-domain networks. An example of a multi-layered network can
be a virtualised network, but also using different technologies. The multi-domain network
descriptions can include aggregated or abstracted network topologies. NML can not only
describe a primarily static network topology, but also its potential capabilities (services) and
its configuration.
NML is aimed at logical connection-oriented network topologies, more precisely topologies
where switching is performed on a label associated with a flow, such as a VLAN, wavelength
or time slot. NML can also be used to describe physical networks or packet-oriented networks,
although the current base schema does not contain classes or properties to explicitly deal
with signal degradation, or complex routing tables.
NML only attempts to describe the data plane of a computer network, not the control plane.

4
GFD-R-P.206 May 2013

It does contain extension mechanism to easily tie it with network provisioning standards and
with network monitoring standards.
Finally, this document omits a definition for the terms Network or capacity. This has been
a conscious choice. The term Network has become so widely used for so many diverse
meanings that it is impossible to create a definition that everyone can agree on, while still
expressing something useful. See Topology for the concept of a network domain and a Link
with multiple sources and sinks for the concept of a local area network. The term capacity is
used by different technologies in such a different way (e.g. including or excluding the header
and footer overhead) that it is better to let technology-specific extensions make an explicit
definition.

1.3 Notational Conventions

The keywords “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should
not”, “recommended”, “may”, and “optional” are to be interpreted as described in
[RFC 2119].
This schema defines classes, attributes, relations, parameters and logic. Objects are instances
of classes, and the type of an object is a class.
Names of classes are capitalised and written in italics (e.g. the Node class). Names of relations
are written in camel case and in italics (e.g. the hasNode relation). Names of identifiers and
string literals are written in monospaced font (e.g. Port_X:in).

1.4 Diagrammatic Conventions

Diagrams in this document follow the conventions of UML class diagrams.
• A subclass-superclass relationship is represented by a line with hollow triangle shape
pointing to the superclass.
• A whole-part relationship is represented by a line with a hollow diamond shape pointing
to the whole (group).
• A entity-relationship is represented by a line, optionally with numbers at each end
indicating the cardinality of the relation. A named entity-relationship has a verb
next to the line, and a filled triangle pointing to the object of the verb. (e.g. the
entitity-relationship BidirectionalPort hasPort § Port is named hasPort, and
* 2
each BidirectionalPort is related to exactly 2 Ports, and each Port may be associated
with zero, one or more BidirectionalPorts.)

5
GFD-R-P.206 May 2013

2 NML Base Schema

The NML Base schema describes an information model for computer networks. This schema
is kept intentionally general, with provisions to extend the schema to describe layer-specific
information.
The schema consists of classes, attributes, relations, and parameters. Classes describe types
of objects and are described in section 2.1. Relations describe the relations between classes
and are described in section 2.2. Attributes describe properties of classes. Parameters,
like attributes, are properties of classes, but may (subtly) change the logic. Attributes and
parameters are described with their class description.
All classes, relations, attributes and parameters defined in this document have an identifier
within the namespace http://schemas.ogf.org/nml/2013/05/base#.

2.1 Classes
Figure 1 shows an overview of all the classes in the NML schema in a UML class diagram.
Each box defines the name of a class, a short description, and possible attributes with their

Network Object Location

name: string name: string
id: URI id: URI
version: timestamp unlocode: UNLOCODE
Group lat: float
long: float
alt: float
Service address: vCard
Topology
Connected graph
Node Lifetime
A device, or partition of Switching Service start: timestamp
a device Ability to create a Link Port Group end: timestamp
(cross connect) Collection of Ports
encoding: URI encoding: URI
labelSwapping: boolean Label
Port
Logical (virtual) directed labeltype: URI
interface at a certain Adaptation Service Link Group value: type dependant
layer Ability to create a given Collection of Links
encoding: URI adaptation encoding: URI
adaptationFunction: URI Label Group
labeltype: URI
Link Bidirectional Port values: type dependant
Logical (virtual) directed Deadaptation encoding: URI
data transport between Service
Ports Ability to create a given Ordered List
encoding: URI deadaptation Bidirectional Link Ordered list of Network
noReturnTraffic: boolean adaptationFunction: URI encoding: URI Objects

Figure 1: A UML class diagram of the classes in the NML schema and their hierarchy

6
GFD-R-P.206 May 2013

value type. In the sections below we discuss each of the elements of the schema.

2.1.1 Network Object

The basic abstract class of the schema is the Network Object. Most classes inherit from it.
Network Object is an abstract class. It must not be instantiated directly.
A Network Object may have the following relations:
• existsDuring to one or more Lifetimes
• isAlias to one or more Network Objects
• locatedAt to one Location
A Network Object may have the following attributes:
• id to assign a persistent globally unique URI
• name to assign a human readable string
• version to assign a time stamp
The meaning of the isAlias relation is only defined for specific cases (between objects of the
same concrete class), and should not be used between other objects.
The meaning of the version attribute is only defined for specific cases (for objects of the
Topology class), and should not be used in other objects. Clients that receive a version
attribute for a non-Topology object should ignore that attribute.
An id is a persistent, globally unique object identifier for the Network Object. The id should
be used to refer to this object. Section 3 describes these identifiers in detail.
name is a human readable string. A name may be written in any language, but it is rec-
ommended that names are chosen so that all users can easily distinguish between different
names. Names are not globally unique, and two objects can have the same name. It is
recommended to use short, descriptive names. A name must not be used for anything
other than display purposes. Normal Unicode recommendations apply: A name must not
contain control or formatting codepoint, and it is recommended to only use codepoints
from the Basic Multilingual Plane (BMP).
version is a time stamp formatted as ISO 8601 calendar date, and must be a basic (compact)
representation with UTC timezone (YYYYMMDD Thhmmss Z) [ISO 8601]. The time stamp can
be used to publish updates of a Topology. If a client receives multiple Topology descriptions,
each with a different version time stamp, the version with the latest time stamp in the past or
present must be considered the valid description. Topology descriptions with a time stamp

7
GFD-R-P.206 May 2013

in the future may be discarded or cached until the denoted time. See also the Lifetime
object to describe historic or future network changes.
The base Network Object is subclassed into the top-level topology components, that are
sufficient to cover the description of networks. The classes in this schema that directly
inherit from Network Object are:
• Node
• Port
• Link
• Service
• Group
These classes are described in more detail below.

2.1.2 Node

A Node is generally a device connected to, or part of, the network. A Node does not
necessarily correspond to a physical machine.
Node inherits from Network Object.
A Node may have the following relations:
• existsDuring to one or more Lifetimes
• hasInboundPort to one or more Ports or PortGroups
• hasOutboundPort to one or more Ports or PortGroups
• hasService to one or more Services of type Switch
• implementedBy to one or more Nodes
• isAlias to one or more Nodes
• locatedAt to one Location
A Node may have the following attributes:
• id to assign a persistent globally unique URI
• name to assign a human readable string

8
GFD-R-P.206 May 2013

2.1.3 Port

A Port defines connectivity from a Network Object to the rest of the network. A Port
object is unidirectional. A Port does not necessarily correspond to a physical interface. It
represents a logical transport entity at a fixed place in the network.
Port inherits from Network Object.
A Port may have the following relations:
• existsDuring to one or more Lifetimes
• hasLabel to one Label
• hasService to one or more Services of type Adaptation or type Deadaptation
• isAlias to one or more Ports
• isSink to one or more Link s
• isSource to one or more Link s
A Port may have the following attributes:
• encoding to assign a data encoding identifier
• id to assign a persistent globally unique URI
• name to assign a human readable string
The encoding attribute defines the format of the data streaming through the Port. The
identifier for the encoding must be a URI. Encoding URIs should be specified in a Grid
Forum Documents (GFD).

2.1.4 Link

A Link object describes a unidirectional data transport from each of its sources to all of its
sinks.
A source of a Link is a Network Object, e.g. a Port, that has a isSource relation to the Link.
A sink of a Link is a Network Object, e.g. a Port, that has a isSink relation to the Link.
A Link object can refer to any link connection. A link segment and an end-to-end path are
both described by a Link object. The composition of links into a path, and decomposition
into link segments is described by the isSerialCompoundLink relation.
Link inherits from Network Object.

9
GFD-R-P.206 May 2013

A Link may have the following relations:

• existsDuring to one or more Lifetimes
• hasLabel to one Label
• isAlias to one or more Link s
• isSerialCompoundLink to one Ordered List of Link s
A Link may have the following attributes:
• encoding to assign a data encoding identifier
• id to assign a persistent globally unique URI
• name to assign a human readable string
A Link may have the following parameter:
• noReturnTraffic. A value of true changes the definition of Link to: data transport
from each sources to all sinks, except that there is no data transport from a source to
a sink if the source and sink are grouped together in a BidirectionalPort group. The
default value of noReturnTraffic is false.
An example of where this is used is in an Ethernet broadcast domain, where broadcast
traffic is sent to all sinks, except the sink Ports associated with the sending source
Port.
The encoding attribute defines the format of the data streaming through the Link. The
identifier for the encoding must be a URI. Encoding URIs should be specified in a Grid
Forum Documents (GFD).

2.1.5 Service

Service describes an ability of the network. That is, it describes how the behavior can be
changed dynamically.
Service is an abstract class. It must not be instantiated directly.
Service inherits from Network Object. A Service may have the same relations, attributes
and parameters as a Network Object.
This schema defines three different services, the SwitchingService the AdaptationService and
the DeadaptationService. These are described in more detail below.

10
GFD-R-P.206 May 2013

2.1.6 Switching Service

A SwitchingService describes the ability to create new Link s from any of its inbound Ports
to any of its outbound Ports.
SwitchingService inherits from Service.
A SwitchingService may have the following relations:
• encoding to assign a data encoding identifier
• existsDuring to one or more Lifetimes
• hasInboundPort to one or more Ports or PortGroups
• hasOutboundPort to one or more Ports or PortGroups
• isAlias to one or more Switching Services
• providesLink to one or more Link s or LinkGroups.
A SwitchingService may have the following attributes:
• id to assign a persistent globally unique URI
• name to assign a human readable string
A SwitchingService may have the following parameter:
• labelSwapping. A value of false adds a restriction to the SwitchingService: it is only
able to create cross connects from an inbound Port to an outbound Port if the Label
of the connected Ports have the same value. The default value is false.
The providesLink relation points to Link s which describe the currently configured cross
connects in a SwitchingService.
A Port object can have a hasService relation, however the SwitchingService defines a more
specific relation hasInboundPort / hasOutboundPort relation to a Port object. The latter
relation is preferred over the hasService relation of the Port to the SwitchingService.
The encoding attribute defines the format of the data streaming through the SwitchingSer-
vice. The identifier for the encoding must be a URI. Encoding URIs should be specified
in a Grid Forum Documents (GFD).

2.1.7 Adaptation Service

An AdaptationService describes the ability that data from one or more Ports can be embed-
ded in the data encoding of one other Port. This is commonly referred to as the embedding

11
GFD-R-P.206 May 2013

of client layer (higher network layer) ports in a server layer (lower network layer) port.
The AdaptationService describes a multiplexing adaptation function, meaning that different
channels (the client layer ports) can be embedded in a single data stream (the server layer
port). For example multiplexing several VLANs over a single trunk port.
Like Port and Link, AdaptationService describes a unidirectional transport function. For
the inverse transport function, see DeadaptationService.
AdaptationService inherits from Service.
An AdaptationService may have the following relations:
• canProvidePort to one or more Ports or PortGroups (this describes a ability)
• existsDuring to one or more Lifetimes
• isAlias to one or more AdaptationServices
• providesPort to one or more Ports or PortGroups (this describes a configuration)
An AdaptationService may have the following attributes:
• adaptationFunction to assign an adaptation technology identifier
• id to assign a persistent globally unique URI
• name to assign a human readable string
DeadaptationService is an inverse of AdaptationService. This should not be confused with
an inverse multiplexing adaptation function. An inverse multiplexing adaptation function
embeds a single data stream in multiple underlying data streams. To describes such a
network, the parallelCompound relation can be used, which is a future extension relation,
described in a separate document [Dijkstra13].

2.1.8 De-adaptation Service

A DeadaptationService describes the ability that data of one or more ports can be extracted
from the data encoding of one other port. This is commonly referred to as the extraction of
client layer (higher network layer) ports from the server layer (lower network layer) port. The
DeadaptationService describes a demultiplexing adaptation function, meaning that different
channels (the client layer ports) can be extracted from a single data stream (the server layer
port). For example demultiplexing several VLANs from a single trunk port.
Like Port and Link, AdaptationService describes a unidirectional transport function. For
the inverse transport function, see AdaptationService.
DeadaptationService inherits from Service.

12
GFD-R-P.206 May 2013

A DeadaptationService may have the following relations:

• canProvidePort to one or more Ports or PortGroups
• existsDuring to one or more Lifetimes
• isAlias to one or more DeadaptationServices
• providesPort to one or more Ports or PortGroups
A DeadaptationService may have the following attributes:
• adaptationFunction to assign a adaptation technology identifier
• id to assign a persistent globally unique URI
• name to assign a human readable string

2.1.9 Group

A Group describes a collections of objects. Any object can be part of a group, including
another Group. An object can also be part of multiple Groups.
Group is an abstract class. It must not be instantiated directly.
Group inherits from Network Object. A Group may have the same relations, attributes and
parameters as a Network Object.
This schema defines five different Groups:
• Topology
• Port Group
• Link Group
• Bidirectional Port
• Bidirectional Link
These classes are described in more detail below.

2.1.10 Topology

A Topology 1 is a set of connected Network Objects. connected means that there is, or it is
possible to create, a data transport between any two Network Objects in the same Topology,
1
At first this was called a Network, then Graph Network. The term Topology was suggested to avoid the
confusion surrounding the overloaded term Network.

13
GFD-R-P.206 May 2013

provided that there are no policy, availability or technical restrictions.

A Topology may have the following relations:
• existsDuring to one or more Lifetimes
• hasNode to one or more Nodes
• hasInboundPort to one or more Ports or PortGroups
• hasOutboundPort to one or more Ports or PortGroups
• hasService to one or more Service of type Switch
• hasTopology to one or more Topologys
• isAlias to one or more Topologys
• locatedAt to one Location
A Topology may have the following attributes:
• id to assign a persistent globally unique URI
• name to assign a human readable string
• version to assign a serial number
The version attribute is described at the Network Object.

2.1.11 Port Group

A PortGroup is an unordered set of Ports.

A PortGroup may have the following relations:
• existsDuring to one or more Lifetimes
• hasLabelGroup to one LabelGroup
• hasPort to one or more Ports or PortGroups
• isAlias to one or more PortGroups
• isSink to one or more LinkGroups
• isSource to one or more LinkGroups
A PortGroup may have the following attributes:
• encoding to assign a data encoding identifier

14
GFD-R-P.206 May 2013

• id to assign a persistent globally unique URI

• name to assign a human readable string

2.1.12 Link Group

A LinkGroup is an unordered set of Link s.

A LinkGroup may have the following relations:
• existsDuring to one or more Lifetimes
• hasLabelGroup to one LabelGroup
• hasLink to one or more Link s or LinkGroups
• isAlias to one or more LinkGroups
• isSerialCompoundLink to Ordered List of LinkGroups
A LinkGroup may have the following attributes:
• id to assign a persistent globally unique URI
• name to assign a human readable string

2.1.13 Bidirectional Port

A BidirectionalPort is a group of two (unidirectional) Ports or PortGroups together forming

a bidirectional representation of a physical or virtual port. See Figure 2 for an example of a
BidirectionalPort and its associated Ports.
A BidirectionalPort may have the following relations:
• existsDuring to one or more Lifetimes
• hasPort to exactly two Ports or two PortGroups
A BidirectionalPort may have the following attributes:
• encoding to assign a data encoding identifier
• id to assign a persistent globally unique URI
• name to assign a human readable string
There is explicitly no direct relation between a BidirectionalPort and a BidirectionalLink,
since NML is a unidirectional model.

15
GFD-R-P.206 May 2013

Bidirectional Port Bidirectional Link

A bi-A-B

hasPort hasLink

Port isSource Link

hasPort A-out A-B hasLink

Port isSink Link

A-in B-A

Figure 2: An abstract example of BidirectionalPort and BidirectionalLink

2.1.14 Bidirectional Link

A BidirectionalLink is a group of two (unidirectional) Link s or LinkGroups together forming

a bidirectional link. See Figure 2 for an example of a BidirectionalLink and its associated
Link s.
A BidirectionalLink may have the following relations:
• existsDuring to one or more Lifetimes
• hasLink to exactly two Link s or two LinkGroups
A BidirectionalLink may have the following attributes:
• encoding to assign a data encoding identifier
• id to assign a persistent globally unique URI
• name to assign a human readable string
There is explicitly no direct relation between a BidirectionalPort and a BidirectionalLink,
since NML is a unidirectional model.

2.1.15 Location

A Location is a reference to a geographical location or area. A Location object can be related

to other Network Objects to describe that these are located there. This can be relevant for
network measurements, visualisations, et cetera.
A Location may have the following attributes:

16
GFD-R-P.206 May 2013

• id to assign a persistent globally unique URI

• name to assign a human readable string
• long is the longitude in WGS84 coordinate system (in decimal degrees) [WGS84]
• lat is the latitude in WGS84 coordinate system (in decimal degrees)
• alt is the altitude in WGS84 coordinate system (in decimal meters)
• unlocode is the UN/LOCODE location identifier [UNLOCODE]
• address is a vCard ADR (address) property. The exact syntax of the address property
is not specified, to allow other (e.g. XML or RDF) representations of the string-based
format specified in [RFC 6350].

2.1.16 Lifetime

A Lifetime is an interval between which the object is said to be active. This can be used to
track changes in a network, reflect dynamic operations, to help debug problems, et cetera.
A Lifetime may have the following attributes:
• start is the start time and date formatted as ISO 8601 calendar date, and should be a
basic (compact) representation with UTC timezone (YYYYMMDD Thhmmss Z) [ISO 8601]
• end is the end time and date formatted as ISO 8601 calendar date, and should be a
basic (compact) representation with UTC timezone (YYYYMMDD Thhmmss Z)
Objects with multiple lifetimes mean that the lifetime of the object is the union of all lifetimes
(as opposed to a intersection).
If a Network Object has no associated Lifetime objects, or the start or end attribute of a
Lifetime object is missing, the default lifetime may be assumed to start on or before the
time specified in the version attribute of the most specific Topology object that contains
this Network Object. The end of that assumed lifetime is indefinite, until a Topology object
with a higher version number is published. This new description can define a new Lifetime
for the object, or the Topology. If the new description does not contain the Network Object,
the end time is assumed to have passed.
If a Network Object has no associated Lifetime objects, and the Topology object does not
have a version attribute, than the lifetime of the Network Object is undefined.

17
GFD-R-P.206 May 2013

2.1.17 Label

A Label is the technology-specific value that distinguishes a single data stream (a channel)
embedded in a larger data stream. The Label can be a resource label (with one value). In a
future extension it may be a pair of source and destination labels (with two values) [G.800].
Examples of resource labels are a VLAN number, wavelength, et cetera.
A Label may have the following attributes:
• labeltype to refer to a technology-specific labelset, e.g. a URI for VLANs
• value is one specific value taken from the labelset, e.g. a VLAN number
Technology extensions of NML may define additional attributes. Label type URIs should
be specified in a Grid Forum Documents (GFD), which should also define possible values.
This version of NML only deals with resource labels. The use of source and destination
labels is a future extension [Dijkstra13].

2.1.18 Label Group

A LabelGroup is an unordered set of Label s.

A LabelGroup may have the following attributes:
• labeltype to refer to a technology-specific labelset
• values is a set of specific values taken from the labelset
Technology extensions of NML may define additional attributes.

2.1.19 Ordered List

An Ordered List is an ordered list of Network Objects. These are used for the isSerialCom-
poundLink relation to an ordered list of Link s to describe a path through the network.
The representation of an Ordered List depends on the syntax, and is defined in section 4.4.

2.1.20 List Item

A ListItem is a syntactical construct which may be used by syntaxes to construct a Ordered

List. The exact usage depends on the syntax.

18
GFD-R-P.206 May 2013

2.2 Relations
Relations describe how different Network Objects relate to each other, typically to form a
network topology description. The relations have been listed above, and are defined here (in
alphabetical order). In principle a Relation can go from any object to any other object.
The list below makes a distinction between allowed and defined relations. An allowed relation
means it is valid NML. A defined relation means that it has a specific meaning, as described
here.
A relation which is not allowed must be rejected by a client, and the sender should be
notified with an error. A relation which is allowed, but (yet) undefined should be ignored
by a client (either silently, or with a warning to the sender). This distinction allows future
extension of NML, while retaining limited backward compatibility.
The existsDuring, hasLabel, hasLabelGroup, hasLink, hasNode, hasPort, hasService, hasTopol-
ogy, locatedAt, providesLink, and providesPort are defined as implicit relations. All other
relations are explicit. The distinction between implicit and explicit relations may be used by
a syntax to allow a more compact network description.

2.2.1 canProvidePort

canProvidePort is used to relate an AdaptationService or DeadaptationService to one or

more Ports or PortGroups to define that these can be created by that AdaptationService or
DeadaptationService.
Allowed relations are:
• Service canProvidePort § Port
* *
• Service canProvidePort § PortGroup
* *
Defined relations are:
• AdaptationService canProvidePort § Port
* *
• AdaptationService canProvidePort § PortGroup
* *
• DeadaptationService canProvidePort § Port
* *
• DeadaptationService canProvidePort § PortGroup
* *

19
GFD-R-P.206 May 2013

2.2.2 existsDuring

existsDuring relates one Network Object object to zero or more LifeTime objects. This
defines the existence of the object at a certain time.

Network Object existsDuring § LifeTime

1 *
Objects with multiple lifetimes mean that the lifetime of the object is the union of all lifetimes
(as opposed to a intersection).
If a Network Object has no associated Lifetime objects, or the start or end attribute of a
Lifetime object is missing, the default lifetime may be assumed to start on or before the
time specified in the version attribute of the most specific Topology object that contains this
Network Object, and the end on or later than the version attribute of the next published
Topology object.
If a Network Object has no associated Lifetime objects, and the Topology object does not
have a version attribute, then the lifetime of the Network Object is undefined.

2.2.3 hasInboundPort

hasInboundPort defines the relation between a Node, a SwitchingService or a Topology and

their respective Ports or PortGroups
Allowed relations are:
• Network Object hasInboundPort § Port
* *
• Network Object hasInboundPort § PortGroup
* *
Defined relations are:
• Node hasInboundPort § Port
* *
• Node hasInboundPort § PortGroup
* *
• SwitchingService hasInboundPort § Port
* *
• SwitchingService hasInboundPort § PortGroup
* *
• Topology hasInboundPort § Port
* *
• Topology hasInboundPort § PortGroup
* *

20
GFD-R-P.206 May 2013

This defines that the related Network Object has an inbound Port or PortGroup object. The
direction of the Port object is relative to the Network Object the Port is attached to, so in
this case the traffic flows towards that Network Object (similarly for the PortGroup). This
Port would then be related to a Link object using the isSink relation (or a PortGroup and
LinkGroup respectively).
A Network Object with a hasInboundPort relation pointing to a PortGroup has the same
meaning as defining a hasInboundPort relation pointing to every Port in that PortGroup (as
defined by a hasPort relation between the PortGroup and Port).

2.2.4 hasLabel

hasLabel assigns one Label to a Port or Link

Allowed relations are:
• Port hasLabel § Label
1 *
• Link hasLabel § Label
1 *
The Label assigned to a Port or Link is the technology label that identifies the traffic through
this Port or Link (including in Link s provided by a SwitchingMatrix ).
A Label is used to distinguish a Port in a PortGroup, or distinguish a Link in a LinkGroup.
The meaning of hasLabel is only defined for a cardinality of 0 or 1.

2.2.5 hasLabelGroup

hasLabelGroup assigns one LabelGroup to a PortGroup or LinkGroup

Allowed relations are:
• PortGroup hasLabelGroup § LabelGroup
1 *
• LinkGroup hasLabelGroup § LabelGroup
1 *
The LabelGroup assigned to this PortGroup or LinkGroup defines the Label s associated with
the Ports member of that group. There must be a one-to-one correspondence between the
LabelGroup and the PortGroup.
The meaning of hasLabelGroup is only defined for a cardinality of 0 or 1.

21
GFD-R-P.206 May 2013

2.2.6 hasLink

hasLink is used for:

• BidirectionalLink to relate exactly two Link s or two LinkGroups
• LinkGroup to one or more Link s or LinkGroups to define membership of that group
Allowed relations are:
• Group hasLink § Link
* *
• Group hasLink § LinkGroup
* *
Defined relations are:
• LinkGroup hasLink § Link
* *
• LinkGroup hasLink § LinkGroup
* *
• BidirectionalLink hasLink § Link
* 2
• BidirectionalLink hasLink § LinkGroup
* 2
The hasLink relationships for a BidirectionalLink point to the two unidirectional Link s that
together form a bidirectional connection between its respective associated Nodes.
The hasLink relationships for a LinkGroup define the membership of the Link s in that
LinkGroup.

2.2.7 hasNode

hasNode relates a Topology to a Node, meaning that a Node is part of a Topology

Allowed relations are:
• Network Object hasNode § Node
* *
Defined relations are:
• Topology hasNode § Node
* *
2.2.8 hasOutboundPort

hasOutboundPort relates either a Node, SwitchingService or a Topology to one or more Ports

or PortGroups.

22
GFD-R-P.206 May 2013

Allowed relations are:

• Network Object hasOutboundPort § Port
* *
• Network Object hasOutboundPort § PortGroup
* *
Defined relations are:
• Node hasOutboundPort § Port
* *
• Node hasOutboundPort § PortGroup
* *
• SwitchingService hasOutboundPort § Port
* *
• SwitchingService hasOutboundPort § PortGroup
* *
• Topology hasOutboundPort § Port
* *
• Topology hasOutboundPort § PortGroup
* *
This defines that the related Network Object has an outbound Port or PortGroup object.
The direction of the Port object is relative to the Network Object the Port is attached to, so
in this case the traffic flows away from that Network Object (similarly for the PortGroup).
This Port would then be related to a Link object using the isSource relation (or az PortGroup
and LinkGroup respectively).
A Network Object with a hasOutboundPort relation pointing to a PortGroup has the same
meaning as defining a hasOutboundPort relation pointing to every Port in that PortGroup
(as defined by a hasPort relation between the PortGroup and Port).

2.2.9 hasPort

hasPort is used for:

• BidirectionalPort to relate exactly two Ports or two PortGroups
• PortGroup to one or more Ports or PortGroups
Allowed relations are:
• Group hasPort § Port
* *
• Group hasPort § PortGroup
* *
Defined relations are:

23
GFD-R-P.206 May 2013

• PortGroup hasPort § Port

* *
• PortGroup hasPort §PortGroup
* *
• BidirectionalPort hasPort § Port
* 2
• BidirectionalPort hasPort § PortGroup
* 2
The hasPort relationships for a BidirectionalPort point to the two unidirectional Ports
that together form a bidirectional port for the associated Node. These Ports would have a
hasInboundPort and hasOutboundPort relation with that Node.
The hasPort relationships for a PortGroup define the membership of the Ports in that
PortGroup.

2.2.10 hasService

hasService relates a Network Object to a Service. This schema only defines the meaning of:
• Port to AdaptationService, relating one server-layer Port to an adaptation function.
• Port to DeadaptationService, relating one server-layer Port to a deadaptation function.
• Node or Topology to SwitchingService, describing a switching ability of that Node or
Topology.
Allowed relations are:
• Network Object hasService § Service
* *
Defined relations are:
• Port hasService § AdaptationService
1 *
• Port hasService § DeadaptationService
1 *
• Node hasService § SwitchingService
* *
• Topology hasService § SwitchingService
* *
A Port object can have a hasService relation to a Service, however the SwitchingService de-
fines a more specific relation hasInboundPort / hasOutboundPort relation to a Port object.
The latter relation is preferred over the hasService relation of the Port to the SwitchingSer-
vice.

24
GFD-R-P.206 May 2013

2.2.11 hasTopology

hasTopology defines a relation between one Topology to one or more Topologys for aggregation
purposes.
Allowed relations are:
• Network Object hasTopology § Topology
* *
Defined relations are:
• Topology hasTopology § Topology
* *
2.2.12 implementedBy

implementedBy relates a Node to one or more Nodes to describe virtualization or partitioning

of a Node. The relation may be recursive, thus a virtual Node may be further partitioned.
Allowed relations are:
• Network Object implementedBy § Network Object
* *
Defined relations are:
• Node implementedBy § Node
* *
2.2.13 isAlias

isAlias is a relation from a Network Object to a Network Object to describe that one can be
used as the alias of another.
Allowed relations are:
• Network Object isAlias § Network Object
* *
The relation is only defined if the type of both objects is the same (e.g. a Node can be related
to another Node, but if it is related to a Topology using the isAlias relation, that relation is
undefined.)

2.2.14 isSerialCompoundLink

isSerialCompoundLink is used to define that a Link or LinkGroup represents an Ordered List

of Link s or LinkGroups. This must include cross-connects.
The following relation is allowed and defined:

25
GFD-R-P.206 May 2013

1. Link
2. Link
• Link isSerialCompoundLink §
1 * ...
n. Link
The following relation is allowed, but undefined:

1. LinkGroup
isSerialCompoundLink § 2. LinkGroup
• LinkGroup
* * ...
n. LinkGroup

2.2.15 isSink

isSink relates a Port to one Link to define the outgoing traffic port, and similarly for Port-
Group and LinkGroup.
Allowed relations are:
• Network Object isSink § Link
* *
• Network Object isSink § LinkGroup
* *
Defined relations are:
• Port isSink § Link
* *
• PortGroup isSink § LinkGroup
* *
isSink between a PortGroups and a LinkGroup is defined only if the PortGroup and LinkGroup
in question have the exact same LabelGroup.

2.2.16 isSource

isSource relates a Port to one Link to define its incoming traffic port, and similarly for
PortGroup and LinkGroup.
Allowed relations are:
• Network Object isSource § Link
* *
• Network Object isSource § LinkGroup
* *
Defined relations are:

26
GFD-R-P.206 May 2013

• Port isSource §
Link
* *
• PortGroup isSource § LinkGroup
* *
isSource between a PortGroups and a LinkGroup is defined only if the PortGroup and
LinkGroup in question have the exact same LabelGroup.

2.2.17 item

A item relation is a syntactical construct which may be used by syntaxes to construct a

Ordered List. The exact usage depends on the syntax.

2.2.18 locatedAt

locatedAt relates a Network Object to one Location to describe that a Network Object is
located at that Location.
• Network Object locatedAt § Location
* *
2.2.19 next

next relation is a syntactical construct which may be used by syntaxes to construct a Ordered
List. The exact usage depends on the syntax.

2.2.20 providesLink

providesLink is used to relate a SwitchingService to one or more Link s or LinkGroups to

define that these have been created by that SwitchingService.
Allowed relations are:
• Service providesLink § Link
* *
• Service providesLink § LinkGroup
* *
Defined relations are:
• SwitchingService providesLink § Link
1 *
• SwitchingService providesLink § LinkGroup
1 *

27
GFD-R-P.206 May 2013

2.2.21 providesPort

providesPort is used to relate an AdaptationService or DeadaptationService to one or more

Ports or PortGroups to define that these have been created by that AdaptationService or
DeadaptationService.
Allowed relations are:
• Service providesPort § Port
* *
• Service providesPort § PortGroup
* *
Defined relations are:
• AdaptationService providesPort § Port
1 *
• AdaptationService providesPort § PortGroup
1 *
• DeadaptationService providesPort § Port
1 *
• DeadaptationService providesPort § PortGroup
1 *

2.3 Attributes
Attributes are properties of an object. The following attributes have been defined in sec-
tion 2.1.

28
GFD-R-P.206 May 2013

Attribute Class (section)

adaptationFunction AdaptationService (2.1.7), DeadaptationService (2.1.8)
address Location (2.1.15)
alt Location (2.1.15)
encoding Port (2.1.3), Link (2.1.4), PortGroup (2.1.11), LinkGroup (2.1.12),
BidirectionalPort (2.1.14), BidirectionalLink (2.1.14),Switch-
ingService (2.1.6)
end LifeTime (2.1.16)
id NetworkObject (2.1.1), Location (2.1.15)
labeltype Label (2.1.17), LabelGroup (2.1.18)
lat Location (2.1.15)
long Location (2.1.15)
name NetworkObject, Location (2.1.15)
start LifeTime (2.1.16)
unlocode Location (2.1.15)
value Label (2.1.17)
values LabelGroup (2.1.18)
version NetworkObject (2.1.1)

2.4 Parameters
Parameters are properties of an object. Parameters, like attributes, are properties of objects,
but may (subtly) change the logic of the object. The following parameters have been defined
in section 2.1.
Parameter Class (section)
labelSwapping SwitchingService (2.1.6)
noReturnTraffic Link (2.1.4)

29
GFD-R-P.206 May 2013

3 Identifiers
3.1 Schema Identifier
The namespace for the schema defined in document is http://schemas.ogf.org/nml/2013/
05/base\#.
All classes, relations, parameters and attributes defined in this document reside in this names-
pace. For example, the Link class is identified by http://schemas.ogf.org/nml/2013/05/base#Link

3.2 Instance Identifiers

Section 2.1.1 requires that instances of Network Objects should have an id attribute, which
must be a unique URI.
Implementations that receive a network topology description must be prepared to accept
any valid URI as an identifier.
Implementations that publish a network topology description instance identifiers may adhere
to the syntax of Global Network Identifiers as defined in [GFD.202], which ensures global
uniqueness and easy recognition as Network Object instances.
Two different Network Objects instances must have two different identifiers.
Once an identifier is assigned to a resource, it must not be re-assigned to another resource.
A URI may be interpreted as an International Resource Identifier (IRI) for display purposes,
but URIs from external source domains must not be IRI-normalised before transmitting
to others.

3.2.1 Lexical Equivalence

Two identifier are lexical equivalent if they are binary equivalent after case folding2 [Unicode].
Other interpretation (such as percent-decoding or Punycode decoding [RFC 3492]) must
not take place.
For the purpose of equivalence comparison, any possible fragment part or query part of the
URI is considered part of the URI.
For example the following identifiers are equivalent:
2
Case folding is primarily used for caseless comparison of text. Case mapping is used for display purposes.

30
GFD-R-P.206 May 2013

1 - urn:ogf:network:example.net:2013:local_string_1234
2 - URN:OGF:network:EXAMPLE.NET:2013:Local_String_1234
While the following identifiers are not equivalent (in this case, the percentage encoding even
makes URI #3 an invalid Global Network Identifier.):
1 - urn:ogf:network:example.net:2013:local_string_1234
3 - urn:ogf:network:example.net:2013:local%5Fstring%5F1234

3.2.2 Further Restrictions

An assigning organisation must not assign Network Object Identifier longer than 255 char-
acters in length.
Parsers must be prepared to accept identifiers of up to 255 characters in length.
A Parser should verify if an identifier adheres to the general URI syntax rules, as specified
in RFC 3986 [RFC 3986].
Parsers should reject identifiers which do not adhere to the specified rules. A parser en-
countering an invalid identifier should reply with an error code that includes the malformed
identifier, but may accept the rest of the message, after purging all references to the Network
Object with the malformed identifier.

3.2.3 Interpreting Identifiers

A Network Object identifier must be treated as a opaque string, only used to uniquely
identify a Network Object. The local-part of a Global Network Identifier may have certain
meaning to it’s assigning organisation, but must not be interpreted by any other organi-
sation.

3.2.4 Network Object Attribute Change

A Network Object may change during its lifetime. If these changes are so drastic that
the assigning organisation considers it a completely new Network Object, the assigning
organisation should be assigned a new identifier. In this case, other organisations MUST
treat this object as completely new Network Resource.
If the assigning organisation considers the changes are small, it must retain the same identi-
fier for the Network Object, and use some mechanism to signal it’s peers of the changes in the
attributes of the Network Object. An appropriate mechanism is to send a new description
of the Topology or the Network Object with an updated version attribute.

31
GFD-R-P.206 May 2013

3.3 Unnamed Objects

Network Objects that do not have a regular URI as id attribute, may have either:
• Have no id attribute. These are so-called unnamed network objects.
• Have an id attribute which is a fragment identifier only, thus an URI starting with a
crosshatch (#) character. These are so-called ad-hoc named network objects.
A unnamed network object can not be referenced. A network objects generally should not
be unnamed, since there is no possibility for an external party to refer to the object.
A ad-hoc named network object can only be referenced from within the same topology
description. ad-hoc id s must be considered a syntactical construct, not as a persistent
identifier. The must not be referred to from another scope or another topology description.
ad-hoc id s should not be stored. If a two peers exchange topology messages, it is perfectly
valid to change the ad-hoc id in each message (since they are only valid within scope of that
message anyway).
A possible reason to use unnamed or ad-hoc named network objects it to make a statement
such as “Port A and Port B are grouped in a BidirectionalPort” without actually assigning
an identifier to this BidirectionalPort.

32
 GFD-R-P.206 May 2013

4 Syntax
The Network Markup Language has two different normative syntaxes. The syntaxes are
in regular XML defined using an XML Schema (XSD), and another in OWL RDF/XML
syntax, defined in an OWL schema. The OWL syntax is aimed at Semantic Web-oriented
applications, the XML syntax is suitable for any application. These syntaxes are defined in
Appendices A and B respectively. These syntaxes follow the model as defined in section 2,
should there be any inconsistencies between the syntaxes or the syntaxes and the model, the
definitions in section 2 take precedence.

4.1 XML Syntax

An NML object is represented as an XML element. For example:

1 <nml:BidirectionalLink />

An NML attribute or parameter is represented as either an XML attribute, XML child

element or text value of the XML element. The table list the mapping for the attributes and
parameters defined in this document:
XML representation Attribute Child element Text of element
NML attribute or parameter id name value
adaptationFunction address values
encoding lat
labeltype long
version alt
noReturnTraffic unlocode
labelSwapping start
end
For example:

1 <nml:Port id="urn:ogf:network:example.net:2013:port_X.1501:in">
2 <nml:name>VLAN 1501 at Port X (in)</nml:name>
3 <nml:Label labeltype="http://schemas.ogf.org/nml/2013/05/ethernet#vlan">1501</nml:Label>
4 </nml:Port>

Explicit relation are represented as a <nml:Relation> XML element, with the domain as
the parent element, and the range as the child element. Implicit relations are not given: the
range object is represented as an XML child element of the domain. Below is an example of
an explicit relation:

33
 GFD-R-P.206 May 2013

1 <nml:Port id="urn:ogf:network:example.net:2013:port_X:in">
2 <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#isSource">
3 <nml:Link id="urn:ogf:network:example.net:2013:linkA:XY"/>
4 </nml:Relation>
5 </nml:Port>

And this is an example of an implicit relation:

1 <nml:Topology id="urn:ogf:network:example.net:2013:Example_Network">
2 <nml:Node id="urn:ogf:network:example.net:2013:example_node"/>
3 </nml:Port>

4.2 OWL RDF/XML Syntax

An NML object is represented as an RDF subject. Exceptions are Label and LabelGroup.
An NML attribute or parameter is represented as a predicate.
For example:

1 <nml:Location id="urn:ogf:network:example.net:2013:redcity">
2 <nml:name>Red City</nml:name>
3 <nml:lat>30.600</nml:lat>
4 <nml:long>12.640</nml:long>
5 </nml:Location>

Relations are represented as an RDF triplet, with the full URI of the attribute or parameter.
For example:

1 <nml:Port rdf:about="urn:ogf:network:example.net:2013:port_X:in">
2 <nml:isSource rdf:resource="urn:ogf:network:example.net:2013:linkA:XY"/>
3 </nml:Port>

A Label is represented as a two triplets: one triplet defining a labeltype as a subproperty of

the abstract Label resource, and one relating a Port or Link to a value using this labeltype.
For example:

1 <rdf:Description rdf:about="http://schemas.ogf.org/nml/2013/05/ethernet#vlan">
2 <owl:subPropertyOf rdf:resource="http://schemas.ogf.org/nml/2013/05/base#hasLabel"/>
3 </rdf:Description>
4 <nml:Port rdf:about="urn:ogf:network:example.net:2013:port_X.1501:in">
5 <nmleth:vlan>1501</nmleth:vlan>
6 </nml:Port>

34
 GFD-R-P.206 May 2013

A LabelGroup is represented as three triplets. The URI of the labeltype is not the URI of the
predicate, to avoid naming clashes with the definition of the Label. Instead, the predicate
of the LabelGroup is related to the predicate of the Label using the nml:labeltype property:

1 <rdf:Description rdf:about="http://schemas.ogf.org/nml/2013/05/ethernet#vlans">
2 <nml:labelType rdf:resource="http://schemas.ogf.org/nml/2013/05/ethernet#vlan"/>
3 <owl:subPropertyOf rdf:resource="http://schemas.ogf.org/nml/2013/05/base#hasLabelGroup"/>
4 </rdf:Description>
5 <nml:PortGroup rdf:about="urn:ogf:network:example.net:2013:portgroup_X:out">
6 <nmleth:vlans>1480´1530</nmleth:vlans>
7 </nml:PortGroup>

4.3 Combining Object Descriptions

A given object may have multiple attributes and relations. These attributes and relations
may be described in different places in a syntax. It is up to the parser to combine all
attributes and relations.
NML currently does not have a mechanism to check if a given description of an object is
complete. Thus, it does not distinguish between a full description of an object or merely a
pointer to an object.
Parsers should be aware that the NML descriptions do not provide any guarantee regarding
the integrity nor the authenticity of the description. Parsers are advised to use external
mechanism to avoid that an erroneous description of an object in one (possibly malicious)
topology description pollutes a correct description of the same object in another topology
description.

4.4 Ordered Lists

The range of an isSerialCompoundLink relation is an Ordered List.
Neither XML nor OWL uses the Ordered List directly in the syntax, and have a different
way of constructing ordered lists. XML lists values with additional next relations, while
OWL uses a ListItem class, and the item and next relations.
A ListItem behaves as a class, while item and next behave like relations, with the exception
that these classes and relations are local in scope.
This means that these relations are only valid within the scope of a given Ordered List, but
may not be valid in scope of a different Ordered List. It also means that any identifier given
to these classes may change when the objects are codified in a syntax.

35
GFD-R-P.206 May 2013

For example, consider the following two decompositions of Link Link_1_2_3 into shorter
Links:
Link_1
• Link_1_2_3 isSerialCompoundLink § Link_2
Link_3

isSerialCompoundLink § Link_1
• Link_1_2_3
Link_2_3

In the first Ordered List, there is a next relation from Link_1 to Link_2, while in the second
Ordered List, the next relation is from Link_1 to Link_2_3.
In XML an Ordered List can be constructed by using all objects in the list as child elements,
and using a next relation between consecutive objects in the list to denote ordering.
In OWL an Ordered List can be constructed by creating as many ListItem objects as there
are items in the list. Each ListItem object is correlated with the actual list item using the
item relation, while using a next relation to point to the following ListItem. A predicate
points to the first ListItem in the Ordered List to point to the whole list, which is chained
using the next relation.
See also the isSerialCompoundLink examples in the example section.

36
 GFD-R-P.206

Topology
locatedAt
5 Examples
org Location
redcity
version hasNode

name lat long

20130521
Node
nodeA Red City 30.600 12.640

hasOutboundPort
hasOutboundPort

BidirectionalPort SwitchingService
hasInboundPort
port_X.1501 nodeA:switching hasInboundPort
Service

hasOutboundPort hasInboundPort hasOutboundPort

hasPort
hasInboundPort
hasPort

Port Port Port Port

port_X.1501:out port_X.1501:in providesLink port_Y:out port_Y:in
Group
isSource Port
providesPort providesPort isSink port_Z:in
isSource isSink
AdaptationService DeadaptationService
port_X:out: port_X:in:
adaptationService deadaptationService
hasLabel
Link Link Link
LinkA:XY LinkB:YZ LinkC:ZW
hasService hasService
Group
hasPort Port Port
port_X:out port_X:in 1501
isSerialCompoundLink

1501 Link hasLink

value link_XW
Label hasLink
labeltype
ethernet#vlan Link
link_WX BidirectionalLink
1480-1530 link_XWX
values
PortGroup
Labelgroup
portgroup_X:out hasLabelGroup labeltype
ethernet#vlan

Figure 3: A graphical overview showing the combination of all examples

A graphical overview showing the combination of all the examples is shown in figure 3.

37
May 2013
GFD-R-P.206 May 2013

5.1 Examples in XML

The following snippets represent NML structures in the XML format.
• Topology (section 2.1.10)

1 <nml:Topology xmlns:nml="http://schemas.ogf.org/nml/2013/05/base#"
2 id="urn:ogf:network:example.net:2013:org"
3 version="20130529T121112Z">
4 <nml:Node id="urn:ogf:network:example.net:2013:nodeA">
5
6 <!´´ ... ´´>
7
8 </nml:Node>
9
10 </nml:Topology>

• Node (section 2.1.2)

1 <nml:Node id="urn:ogf:network:example.net:2013:nodeA">
2 <nml:name>Node_A</nml:name>
3 <nml:Location id="urn:ogf:network:example.net:2013:redcity"/>
4 <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#hasOutboundPort">
5 <nml:Port id="urn:ogf:network:example.net:2013:port_X:out"/>
6 <nml:Port id="urn:ogf:network:example.net:2013:port_Y:out"/>
7 </nml:Relation>
8 <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#hasInboundPort">
9 <nml:Port id="urn:ogf:network:example.net:2013:port_X:in"/>
10 <nml:Port id="urn:ogf:network:example.net:2013:port_Y:in"/>
11 </nml:Relation>
12 </nml:Node>

• Ports
– (Unidirectional) Port (section 2.1.3)

1 <nml:Port id="urn:ogf:network:example.net:2013:port_X.1501:in">
2 <nml:Label labeltype="http://schemas.ogf.org/nml/2013/05/ethernet#vlan">1501</nml:Label>
3 </nml:Port>

– BidirectionalPort (section 2.1.13)

1 <nml:BidirectionalPort id="urn:ogf:network:example.net:2013:port_X.1501">
2 <nml:name>X.1501</nml:name>
3 <nml:Port id="urn:ogf:network:example.net:2013:port_X.1501:out"/>
4 <nml:Port id="urn:ogf:network:example.net:2013:port_X.1501:in"/>
5 </nml:BidirectionalPort>

38
GFD-R-P.206 May 2013

– PortGroup (section 2.1.11)

1 <nml:PortGroup id="urn:ogf:network:example.net:2013:portgroup_X:out">
2 <nml:LabelGroup labeltype="http://schemas.ogf.org/nml/2013/05/ethernet#vlan">
3 1480´1530
4 </nml:LabelGroup>
5 <nml:Port id="urn:ogf:network:example.net:2013:port_X.1501:out"/>
6 </nml:PortGroup>

• Links
– UnidirectionalLink (external) (section 2.1.4)

1 <nml:Link id="urn:ogf:network:example.net:2013:linkB:YZ"/>
2
3 <nml:Port id="urn:ogf:network:example.net:2013:port_Y:out">
4 <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#isSource">
5 <nml:Link id="urn:ogf:network:example.net:2013:linkB:YZ"/>
6 </nml:Relation>
7
8 <nml:Port id="urn:ogf:network:example.net:2013:port_Z:in">
9 <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#isSink">
10 <nml:Link id="␣urn:ogf:network:example.net:2013:linkB:YZ"/>
11 </nml:Relation>
12 </nml:Port>
13
14 </nml:Port>

– UnidirectionalLink (internal) (section 2.1.4)

1 <nml:Link id="urn:ogf:network:example.net:2013:linkA:XY"/>
2
3 <nml:Port id="urn:ogf:network:example.net:2013:port_X.1501:in">
4 <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#isSource">
5 <nml:Link id="␣urn:ogf:network:example.net:2013:linkA:XY"/>
6 </nml:Relation>
7 </nml:Port>
8
9 <nml:Port id="urn:ogf:network:example.net:2013:port_Y:out">
10 <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#isSink">
11 <nml:Link id="urn:ogf:network:example.net:2013:linkA:XY"/>
12 </nml:Relation>
13 </nml:Port>

– UnidirectionalLink that is composed of more than one sub-link

1 <nml:Link id="urn:ogf:network:example.net:2013:link_XW">
2 <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#isSerialCompoundLink">
3 <nml:Link id="urn:ogf:network:example.net:2013:linkA:XY">
4 <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#next">
5 <nml:Link id="urn:ogf:network:example.net:2013:linkB:YZ"/>

39
GFD-R-P.206 May 2013

6 </nml:Relation>
7 </nml:Link>
8 <nml:Link id="urn:ogf:network:example.net:2013:linkB:YZ">
9 <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#next">
10 <nml:Link id="urn:ogf:network:example.net:2013:linkC:ZW"/>
11 </nml:Relation>
12 </nml:Link>
13 <nml:Link id="urn:ogf:network:example.net:2013:linkC:ZW"/>
14 </nml:Relation>
15 </nml:Link>

– BidirectionalLink (section 2.1.14)

1 <nml:BidirectionalLink id="urn:ogf:network:example.net:2013:link_XWX">
2 <nml:name>Link between ports X and W</nml:name>
3 <nml:Link id="urn:ogf:network:example.net:2013:link_XW"/>
4 <nml:Link id="urn:ogf:network:example.net:2013:link_WX"/>
5 </nml:BidirectionalLink>

– LinkGroup (section 2.1.12)

1 <nml:LinkGroup id="urn:ogf:network:example.net:2013:domainy_domainx">
2 <nml:LabelGroup labeltype="http://schemas.ogf.org/nml/2013/05/ethernet#vlan">
3 1480´1530
4 </nml:LabelGroup>
5 </nml:LinkGroup>

• Labels
– Label (section 2.1.17)

1 <nml:Label labeltype="http://schemas.ogf.org/nml/2013/05/ethernet#vlan">1501</nml:Label>

– LabelGroup (section 2.1.18)

1 <nml:LabelGroup labeltype="http://schemas.ogf.org/nml/2013/05/ethernet#vlan">
2 1480´1530
3 </nml:LabelGroup>

• Location (section 2.1.15)

1 <nml:Location id="urn:ogf:network:example.net:2013:redcity">
2 <nml:name>Red City</nml:name>
3 <nml:lat>30.600</nml:lat>
4 <nml:long>12.640</nml:long>
5 </nml:Location>

40
GFD-R-P.206 May 2013

• Services
– SwitchingService (section 2.1.6)

1 <nml:Node id="urn:ogf:network:example.net:2013:nodeA">
2 <nml:name>Node_A</nml:name>
3 <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#hasInboundPort">
4 <nml:Port id="urn:ogf:network:example.net:2013:nodeA:port_X:in" />
5 <nml:Port id="urn:ogf:network:example.net:2013:nodeA:port_Y:in" />
6 </nml:Relation>
7 <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#hasOutboundPort">
8 <nml:Port id="urn:ogf:network:example.net:2013:nodeA:port_X:out"/>
9 <nml:Port id="urn:ogf:network:example.net:2013:nodeA:port_Y:out"/>
10 </nml:Relation>
11 <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#hasService">
12 <nml:SwitchingService id="urn:ogf:network:example.net:2013:nodeA:switchingService"/>
13 </nml:Relation>
14 </nml:Node>
15
16 <nml:SwitchingService id="urn:ogf:network:example.net:2013:nodeA:switchingService">
17 <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#hasInboundPort">
18 <nml:Port id="urn:ogf:network:example.net:2013:nodeA:port_X:in" />
19 <nml:Port id="urn:ogf:network:example.net:2013:nodeA:port_Y:in" />
20 </nml:Relation>
21 <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#hasOutboundPort">
22 <nml:Port id="urn:ogf:network:example.net:2013:nodeA:port_X:out"/>
23 <nml:Port id="urn:ogf:network:example.net:2013:nodeA:port_Y:out"/>
24 </nml:Relation>
25 <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#providesLink">
26 <nml:Link id="urn:ogf:network:example.net:2013:LinkA:XY"/>
27 </nml:Relation>
28 </nml:SwitchingService>

– AdaptationService (section 2.1.7)

1 <nml:Port id="urn:ogf:network:example.net:2013:port_X:in">
2 <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#hasService">
3 <nml:AdaptationService id="urn:ogf:network:example.net:2013:port_X:in:adaptationService"/>
4 </nml:Relation>
5 </nml:Port>
6
7 <nml:AdaptationService
8 id="urn:ogf:network:example.net:2013:port_X:in:adaptationService"
9 adaptationFunction="http://schemas.ogf.org/nml/2013/05/ethernet#802.1q">
10 <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#providesPort">
11 <nml:Port id="urn:ogf:network:example.net:2013:port_X.1501:in"/>
12 </nml:Relation>
13 </nml:AdaptationService>
14
15 <nml:Port id="urn:ogf:network:example.net:2013:port_X.1501:in">
16 <nml:Label labeltype="http://schemas.ogf.org/nml/2013/05/ethernet#vlan">1501</nml:Label>
17 </nml:Port>

– DeadaptationService (section 2.1.8)

41
GFD-R-P.206 May 2013

1 <nml:Port id="urn:ogf:network:example.net:2013:port_X:in">
2 <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#hasService">
3 <nml:DeadaptationService id="urn:ogf:network:example.net:2013:port_X.1501
:in:deadaptationService"/>
4 </nml:Relation>
5 </nml:Port>
6
7 <nml:DeadaptationService
8 id="urn:ogf:network:example.net:2013:port_X.1501:in:deadaptationService"
9 adaptationFunction="http://schemas.ogf.org/nml/2013/05/ethernet#802.1q">
10 <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#providesPort">
11 <nml:Port id="urn:ogf:network:example.net:2013:port_X.1501:in"/>
12 </nml:Relation>
13 </nml:DeadaptationService>
14
15 <nml:Port id="urn:ogf:network:example.net:2013:port_X.1501:in">
16 <nml:Label labeltype="http://schemas.ogf.org/nml/2013/05/ethernet#vlan">1501</nml:Label>
17 </nml:Port>

42
GFD-R-P.206 May 2013

5.2 Examples in OWL

The following snippets represent NML structures in the OWL format. The namespaces used
in all the examples follow the definitions of the Topology example.
• Topology (section 2.1.10)

1 <?xml version="1.0" encoding="utf-8"?>

2 <rdf:RDF
3 xmlns:nml="http://schemas.ogf.org/nml/2013/05/base#"
4 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
5 xmlns:owl="http://www.w3.org/2002/07/owl#"
6 xmlns:nmleth="http://schemas.ogf.org/nml/2013/05/ethernet#"
7 >
8 <nml:Topology rdf:about="urn:ogf:network:example.net:2013:org">
9 <nml:version>20130529T121112Z</nml:version>
10 <nml:hasNode rdf:resource="urn:ogf:network:example.net:2013:nodeA"/>
11 <!´´ ... ´´>
12
13 </nml:Topology>

• Node (section 2.1.2)

1 <nml:Node rdf:about="urn:ogf:network:example.net:2013:nodeA">
2 <nml:name>Node_A</nml:name>
3 <nml:locatedAt rdf:resource="urn:ogf:network:example.net:2013:redcity"/>
4 <nml:hasOutboundPort rdf:resource="urn:ogf:network:example.net:2013:nodeA:port_X:out"/>
5 <nml:hasOutboundPort rdf:resource="urn:ogf:network:example.net:2013:nodeA:port_Y:out"/>
6 <nml:hasInboundPort rdf:resource="urn:ogf:network:example.net:2013:nodeA:port_X:in"/>
7 <nml:hasInboundPort rdf:resource="urn:ogf:network:example.net:2013:nodeA:port_Y:in"/>
8 </nml:Node>

• Ports
– (Unidirectional) Port (section 2.1.3)

1 <nml:Port rdf:about="urn:ogf:network:example.net:2013:port_X.1501:in">
2 <nmleth:vlan>1501</nmleth:vlan>
3 </nml:Port>

– BidirectionalPort (section 2.1.13)

1 <nml:BidirectionalPort rdf:about="urn:ogf:network:example.net:2013:port_X.1501">
2 <nml:name>X.1501</nml:name>
3 <nml:hasPort rdf:resource="urn:ogf:network:example.net:2013:port_X.1501:out"/>
4 <nml:hasPort rdf:resource="urn:ogf:network:example.net:2013:port_X.1501:in"/>
5 </nml:BidirectionalPort>

43
GFD-R-P.206 May 2013

– PortGroup (section 2.1.11)

1 <nml:PortGroup rdf:about="urn:ogf:network:example.net:2013:portgroup_X:out">
2 <nmleth:vlans>1480´1530</nmleth:vlans>
3 <nml:hasPort>
4 <nml:Port rdf:about="urn:ogf:network:example.net:2013:port_X.1501:out"/>
5 </nml:hasPort>
6 </nml:PortGroup>

• Links
– UnidirectionalLink (external) (section 2.1.4)

1 <nml:Link rdf:about="urn:ogf:network:example.net:2013:linkB:YZ"/>
2
3 <nml:Port id="urn:ogf:network:example.net:2013:port_Y:out">
4 <nml:isSink rdf:resource="urn:ogf:network:example.net:2013:linkB:YZ"/>
5 </nml:Port>
6
7 <nml:Port rdf:about="urn:ogf:network:example.net:2013:port_Z:in">
8 <nml:isSource rdf:resource="urn:ogf:network:example.net:2013:linkB:YZ"/>
9 </nml:Port>

– UnidirectionalLink (internal) (section 2.1.4)

1 <nml:Link rdf:about="urn:ogf:network:example.net:2013:linkA:XY"/>
2
3 <nml:Port rdf:about="urn:ogf:network:example.net:2013:port_X.1501:in">
4 <nml:isSource rdf:resource="urn:ogf:network:example.net:2013:linkA:XY"/>
5 </nml:Port>
6
7 <nml:Port id="urn:ogf:network:example.net:2013:port_Y:out">
8 <nml:isSink rdf:resource="urn:ogf:network:example.net:2013:linkA:XY"/>
9 </nml:Port>

– UnidirectionalLink that is composed of more than one sub-link

1 <nml:Link rdf:about="urn:ogf:network:example.net:2013:link_XW">
2 <nml:isSerialCompoundLink>
3 <nml:ListItem rdf:resource="urn:ogf:network:example.net:2013:link_XW_1">
4 <nml:item rdf:resource="urn:ogf:network:example.net:2013:linkA:XY"/>
5 <nml:next rdf:resource="urn:ogf:network:example.net:2013:link_XW_2"/>
6 </nml:ListItem>
7 </nml:isSerialCompoundLink>
8 </nml:Link>
9
10 <nml:ListItem rdf:resource="urn:ogf:network:example.net:2013:link_XW_2">
11 <nml:item rdf:resource="urn:ogf:network:example.net:2013:linkB:YZ"/>
12 <nml:next rdf:resource="urn:ogf:network:example.net:2013:link_XW_3"/>
13 </nml:ListItem>
14

44
GFD-R-P.206 May 2013

15 <nml:ListItem rdf:resource="urn:ogf:network:example.net:2013:link_XW_3">
16 <nml:item rdf:resource="urn:ogf:network:example.net:2013:linkC:ZW"/>
17 </nml:ListItem>

– BidirectionalLink (section 2.1.14)

1 <nml:BidirectionalLink rdf:about="urn:ogf:network:example.net:2013:link_XWX">
2 <nml:name>Link between ports X and W</nml:name>
3 <nml:hasLink rdf:resource="urn:ogf:network:example.net:2013:link_XW"/>
4 <nml:hasLink rdf:resource="urn:ogf:network:example.net:2013:link_WX"/>
5 </nml:BidirectionalLink>

– LinkGroup (section 2.1.12)

1 <nml:LinkGroup rdf:about="urn:ogf:network:example.net:2013:domainy_domainx">
2 <nmleth:vlans>1480´1530</nmleth:vlans>
3 </nml:LinkGroup>

• Labels
– Label (section 2.1.17)

1 <rdf:Description rdf:about="http://schemas.ogf.org/nml/2013/05/ethernet#vlan">
2 <owl:subPropertyOf rdf:resource="http://schemas.ogf.org/nml/2013/05/base#hasLabel"/>
3 </rdf:Description>
4 <nml:Port rdf:about="urn:ogf:network:example.net:2013:port_X.1501:in">
5 <nmleth:vlan>1501</nmleth:vlan>
6 </nml:Port>

– LabelGroup (section 2.1.18)

1 <rdf:Description rdf:about="http://schemas.ogf.org/nml/2013/05/ethernet#vlans">
2 <nml:labelType rdf:resource="http://schemas.ogf.org/nml/2013/05/ethernet#vlan"/>
3 <owl:subPropertyOf rdf:resource="http://schemas.ogf.org/nml/2013/05/base#hasLabelGroup"/>
4 </rdf:Description>
5 <nml:PortGroup rdf:about="urn:ogf:network:example.net:2013:portgroup_X:out">
6 <nmleth:vlans>1480´1530</nmleth:vlans>
7 </nml:PortGroup>

• Location (section 2.1.15)

1 <nml:Location id="urn:ogf:network:example.net:2013:redcity">
2 <nml:name>Red City</nml:name>
3 <nml:latitude>30.600</nml:latitude>
4 <nml:longitude>12.640</nml:longitude>
5 </nml:Location>

45
GFD-R-P.206 May 2013

• Services
– SwitchingService (section 2.1.6)

1 <nml:Node rdf:about="urn:ogf:network:example.net:2013:nodeA">
2 <nml:name>Node_A</nml:name>
3 <nml:hasInboundPort rdf:resource="urn:ogf:network:example.net:2013:nodeA:port_X:in"/>
4 <nml:hasInboundPort rdf:resource="urn:ogf:network:example.net:2013:nodeA:port_Y:in"/>
5 <nml:hasOutboundPort rdf:resource="urn:ogf:network:example.net:2013:nodeA:port_X:out"/>
6 <nml:hasOutboundPort rdf:resource="urn:ogf:network:example.net:2013:nodeA:port_Y:out"/>
7 <nml:hasService rdf:resource="urn:ogf:network:example.net:2013:nodeA:switchingService"/>
8 </nml:Node>
9
10 <nml:SwitchingService rdf:about="urn:ogf:network:example.net:2013:nodeA:switchingService">
11 <nml:hasInboundPort rdf:resource="urn:ogf:network:example.net:2013:nodeA:port_X:in"/>
12 <nml:hasInboundPort rdf:resource="urn:ogf:network:example.net:2013:nodeA:port_Y:in"/>
13 <nml:hasOutboundPort rdf:resource="urn:ogf:network:example.net:2013:nodeA:port_X:out"/>
14 <nml:hasOutboundPort rdf:resource="urn:ogf:network:example.net:2013:nodeA:port_Y:out"/>
15 </nml:SwitchingService>

– AdaptationService (section 2.1.7)

1 <nml:Port rdf:about="urn:ogf:network:example.net:2013:port_X:out">
2 <nml:hasService>
3 <nml:AdaptationService
4 rdf:about="urn:ogf:network:example.net:2013:port_X:out:adaptationService">
5 <nml:adaptationFunction rdf:resource="http://schemas.ogf.org/nml/2013/05/ethernet#802.1q"/>
6 <nml:providesPort rdf:resource="urn:ogf:network:example.net:2013:port_X.1501:out"/>
7 </nml:AdaptationService>
8 </nml:hasService>
9 </nml:Port>
10
11 <nml:Port rdf:about="urn:ogf:network:example.net:2013:port_X.1501:out">
12 <nmleth:vlan>1501</nmleth:vlan>
13 </nml:Port>

– DeadaptationService (section 2.1.8)

1 <nml:Port rdf:about="urn:ogf:network:example.net:2013:port_X:in">
2 <nml:hasService>
3 <nml:DeadaptationService
4 rdf:resource="urn:ogf:network:example.net:2013:port_X:in:deadaptationService">
5 <nml:adaptationFunction rdf:resource="http://schemas.ogf.org/nml/2013/05/ethernet#802.1q"/>
6 <nml:providesPort rdf:resource="urn:ogf:network:example.net:2013:port_X.1501:in"/>
7 </nml:DeadaptationService>
8 </nml:hasService>
9 </nml:Port>
10
11 <nml:Port rdf:about="urn:ogf:network:example.net:2013:port_X.1501:in">
12 <nmleth:vlan>1501</nmleth:vlan>
13 </nml:Port>

46
GFD-R-P.206 May 2013

5.3 Conceptual Examples

This section shows a few examples how NML was designed to be used. Like the other
examples, this section is informative. It may be possible that there are other ways to use
the NML objects and attributes.

5.3.1 Topology and Node

A Topology and Node behave similar: they both contain inbound ports and outbound ports,
and can contain a SwitchingService to allow creation of internal links (cross connects) from
inbound ports to outbound ports. Especially with the ability to create logical, sliced or
virtual devices, the distinction is getting blurred.
The distinction is that a Node is located at a single geographic location, while a Topology is
a set of geographically disperse Network Objects.

5.3.2 Hierarchical Topology

Large networks may want to publish both details of their network topology as a whole, as
well as details about regional segments, without publishing details of the actual devices.
NML allows the publication of a hierarchical Topology tree, where the top-level Topology
has a hasTopology relation with smaller Topologies. These smaller Topologies must be fully
enclosed – the hasTopology relation can not be used to relate partial overlapping Topologies.
For example, a Topology A may want to publish about two parts of its Topology, A_West,
and A_East. This allows it to publish difference in connectivity and costs between the two
parts. It can do so with the following relations:
Topology A hasTopology § Topology A_West
Topology A hasTopology § Topology A_East

5.3.3 Links, Segments and Paths

A Link object can refer to any link connection. A link segment and an end-to-end path are
both described by a Link object. This is by design, since it is easy to extend a Link, or to
describe a partition of a Link.
Figure 4 gives an example of three different partitionings of a link between port_X:in and
port_W:out.
Note that in this example Port port_Y:out is the source of both linkB:YZ and of linkBC:YW.
If a single topology description would contain the full link and the partitioning, a path finding

47
GFD-R-P.206 May 2013

LinkA:XY LinkB:YZ LinkC:ZW

X:in Y:out Z:in W:out

LinkAB:XZ LinkC:ZW
X:in Z:in W:out

LinkA:XY LinkBC:YW
X:in Y:out W:out

Figure 4: Different partitionings of the same link.

algoritm must be aware that the fact that if a Port is the source of two NML Links, this does
not mean it multicast to different network links. For this reason, it is recommended that
applications either add metadata about the type of link, or specify that in certain messages,
only one particular type of Link must be used.

5.3.4 Patch Panel and Media Convertor

A port on a patch panel or optical distribution frame can simply be described as a NML
Port (thus without an associated Node):
Port odf_X isSink § Link A
Port odf_X isSource § Link B
A mediaconvertor, e.g. from Ethernet over UTP to Ethernet over fiber, can be described
in the same way, provided that the connected Links described the Ethernet connections. If
the connected Links describe the underlying UTP and fiber connections, it is necessary to
describe the conversion between them:
Port Port_X_UTP isSink § Link UTP_A
Port Port_X_fiber isSource § Link fiber_B
Port Port_X_UTP hasService § DeAdaptataionService X_deadaptation
Port Port_X_fiber hasService §
AdaptationService X_adaptation
DeAdaptataionService X_deadaptation providesPort § Port Port_X_eth
AdaptationService X_adaptation providesPort § Port Port_X_eth

5.3.5 VLAN and Broadcast Medium

A VLAN is much like a broadcast medium, which can be described as a multipoint-to-

multipoint Link:

48
GFD-R-P.206 May 2013

Port Port_X:in isSink § Link VLAN_42

Port Port_X:out isSink § Link VLAN_42
Port Port_Y:in isSink § Link VLAN_42
Port Port_Y:out isSink § Link VLAN_42
Port Port_Z:in isSink § Link VLAN_42
Port Port_Z:out isSink § Link VLAN_42

Where X, Y and Z are in fact bidirectional ports:

BidirectionalPort Port_X hasPort § Port Port_X:in
BidirectionalPort Port_X hasPort § Port Port_X:out
BidirectionalPort Port_Y hasPort § Port Port_Y:in
BidirectionalPort Port_Y hasPort § Port Port_Y:out
BidirectionalPort Port_Z hasPort § Port Port_Z:in
BidirectionalPort Port_Z hasPort § Port Port_Z:out

However, this is not entirely correct: in the above description data coming from Port_X:in
would also be forwarded to Port_X:out. However, the Ethernet technology prevents data
returning on the same interface.
NML introduced the noReturnTraffic parameter to describe this technological restriction: if
the noReturnTraffic parameter of a Link is true, there is no data transport from a source to
a sink if the source and sink are grouped together in a BidirectionalPort group.
Link VLAN_42 noReturnTraffic § "true"

5.3.6 Configuration and Potential Capability

NML is able to both describe the network services (potential capability) as well as the
network configuration.
A switching service can be described by a SwitchingService object along with associated
inbound ports and outbound ports:
SwitchingService switchmatrix_A hasInboundPort § PortGroup Port_X:in
SwitchingService switchmatrix_A hasOutboundPort § PortGroup Port_X:out

49
GFD-R-P.206 May 2013

SwitchingService switchmatrix_A hasInboundPort § PortGroup Port_Y:in

SwitchingService switchmatrix_A hasOutboundPort § PortGroup Port_Y:out
SwitchingService switchmatrix_A labelSwapping § true
A cross connect created by this switching service can be specified by a Link object:
SwitchingService switchmatrix_A providesLink § Link crossconnect_A.1501
PortGroup Port_X:in hasPort § Port Port_X.1501:in
PortGroup Port_Y:out hasPort § Port Port_Y.1501:out
Port Port_X.1501:in isSource § Link crossconnect_A.1501
Port Port_Y.1501:out isSink § Link crossconnect_A.1501
An encoding and decoding service can be described by a AdapdationService and DeAdapta-
tionService:
Port Port_X_fiber:in hasService § DeAdaptationService port_X:in:deadaptation

DeAdaptationService port_X:in:deadaptation canProvidePort § PortGroup Port_X:in

A channel created by this encoding service can be specified by a providesPort relation:

DeAdaptationService port_X:in:deadaptation providesPort § Port Port_X.1501:in

PortGroup Port_X:in hasPort § Port Port_X.1501:in

5.3.7 Versioning and Lifetime

The version of a Topology indicated the serial number. If there are two Topology descriptions
for the same network, the one with the highest version number is the most recent version.
The LifeTime object is used to indicate when a certain resource is available.
Imagine that a link will have a scheduled downtime due to maintenance next week between
2 AM and 4 AM. This can be specified with these relations:
Topology org version § 20130521T000000Z
Link A existsDuring § LifeTime A_lifetime1
Link A existsDuring § LifeTime A_lifetime2
LifeTime A_lifetime1 end § 20130611T020000Z
LifeTime A_lifetime2 start § 20130611T040000Z

50
GFD-R-P.206 May 2013

Imagine that this planned maintainance is rescheduled. That can be specified by creating a
new Topology with a new version number, and updated data:
Topology org version § 20130604T000000Z
Link A existsDuring § LifeTime A_lifetime1
Link A existsDuring § LifeTime A_lifetime2
LifeTime A_lifetime1 end § 20130618T020000Z
LifeTime A_lifetime2 start § 20130618T040000Z

51
GFD-R-P.206 May 2013

6 Security Considerations
There are important security concerns associated with the generation and distribution of
network topology information. For example, ISPs frequently consider network topologies
to be confidential. We do not address these concerns in this document, but implementers
are encouraged to consider the security implications of generating and distributing network
topology information.
Implementers should be aware that the NML descriptions do not provide any guarantee
regarding their integrity nor their authenticity. The NML documents also can not provide
this for the identifiers contained in the documents. Implementers should use external means
of verifying the authenticity of identifiers contained in the documents.

52
GFD-R-P.206 May 2013

7 Contributors
Jeroen J. van der Ham (Editor)
Faculty of Science, Informatics Institute, University of Amsterdam
Science Park 904, 1098 XH Amsterdam
The Netherlands
Email: vdham@uva.nl

Freek Dijkstra
SURFsara
Science Park 140, 1098 XG Amsterdam
The Netherlands
Email: freek.dijkstra@surfsara.nl

Roman Łapacz
PSNC
ul. Noskowskiego 12/14, 61-704 Poznań
Poland
Email: romradz@man.poznan.pl

Jason Zurawski
Internet2
1150 18th Street, NW
Suite 900
Washington, DC 20036
USA
Email: zurawski@es.net

8 Acknowledgments
The authors would like to thank the NML working group members for their patience. The
NML group has operated in the web of infrastructure groups and is grateful for all the input
from the NM, NMC and NSI working-groups.
Financial support has been provided by several projects and institutions:
This work was partially supported by the European Commission, 7th Framework Programme
for Research and Technological Development, Capacities, The GN3 project – Grant No.
238875, GEYSERS – Grant No. 248657 and NOVI – Grant No. 257867. This project
was also made possible by the support of SURF, the collaborative organisation for higher

53
GFD-R-P.206 May 2013

education institutes and research institutes aimed at breakthrough innovations in ICT. More
information on SURF is available on the website www.surf.nl. Furthermore, this work was
supported by the Dutch national program COMMIT.
Jason Zurawski would like to thank Internet2, along with the National Science Foundation
(NSF) for support through grants: #0962704, #1019008, and #0721902.
The authors are indebted to the many participants of working group sessions and on the
mailing list, including the following contributors: Aaron Brown, Jeff W. Boote, Aurélien
Cedeyn, Evangelos Chaniotakis, Chin Guok, Paola Grosso, Richard Hughes-Jones, Houssem
Medhioub, Ralph Niederberger, Anand Patil, Victor Reijs, Guy Roberts, Jerry Sobieski,
Martin Swany, Fausto Vetter, Pascale Vicat-Blanc, and John Vollbrecht.

54
GFD-R-P.206 May 2013

9 Intellectual Property Statement

The OGF takes no position regarding the validity or scope of any intellectual property or
other rights that might be claimed to pertain to the implementation or use of the technology
described in this document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any effort to identify any
such rights. Copies of claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers or users of this specification
can be obtained from the OGF Secretariat.
The OGF invites any interested party to bring to its attention any copyrights, patents
or patent applications, or other proprietary rights which may cover technology that may
be required to practice this recommendation. Please address the information to the OGF
Executive Director.

10 Disclaimer
This document and the information contained herein is provided on an “As Is” basis and the
OGF disclaims all warranties, express or implied, including but not limited to any warranty
that the use of the information herein will not infringe any rights or any implied warranties
of merchantability or fitness for a particular purpose.

11 Full Copyright Notice

Copyright c Open Grid Forum (2008-2013). Some Rights Reserved.
This document and translations of it may be copied and furnished to others, and deriva-
tive works that comment on or otherwise explain it or assist in its implementation may be
prepared, copied, published and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are included as references
to the derived portions on all such copies and derivative works. The published OGF doc-
ument from which such works are derived, however, may not be modified in any way, such
as by removing the copyright notice or references to the OGF or other organizations, except
as needed for the purpose of developing new or updated OGF documents in conformance
with the procedures defined in the OGF Document Process, or as required to translate it
into languages other than English. OGF, with the approval of its board, may remove this
restriction for inclusion of OGF document content for the purpose of producing standards
in cooperation with other international standards bodies.

55
GFD-R-P.206 May 2013

The limited permissions granted above are perpetual and will not be revoked by the OGF
or its successors or assignees.

56
 GFD-R-P.206 May 2013

Appendix A XML Schema

This section describes the normative schema of XML documents using the XML Schema
language.

1 <?xml version="1.0" encoding="UTF-8"?>

2
3
4 <!´´
5
6 File: nmlbase.xsd ´ Main XSD schema definition
7 Version: $Id$
8 Purpose: This is the main XSD schema file, it defines the
9 general topology elements of NML.
10
11 ´´>
12
13 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
14 targetNamespace="http://schemas.ogf.org/nml/2013/05/base#"
15 xmlns:nml="http://schemas.ogf.org/nml/2013/05/base#"
16 elementFormDefault="qualified">
17
18
19 <xs:complexType name="NetworkObject">
20 <xs:sequence>
21 <xs:element name="name" type="xs:string" minOccurs="0" maxOccurs="1"/>
22 <xs:element name="Lifetime" type="nml:LifeTimeType" minOccurs="0" maxOccurs="1"/>
23 <xs:element name="Location" type="nml:LocationType" minOccurs="0" maxOccurs="1"/>
24 </xs:sequence>
25 <xs:attribute name="id" type="xs:anyURI" use="optional"/>
26 <xs:attribute name="version" type="xs:dateTime" use="optional"/>
27 </xs:complexType>
28
29
30 <xs:complexType name="LocationType">
31 <xs:all>
32 <xs:element name="name" type="xs:string" minOccurs="0" maxOccurs="1"/>
33 <xs:element name="long" type="xs:float" minOccurs="0" maxOccurs="1"/>
34 <xs:element name="lat" type="xs:float" minOccurs="0" maxOccurs="1"/>
35 <xs:element name="alt" type="xs:float" minOccurs="0" maxOccurs="1"/>
36 <xs:element name="unlocode" type="xs:string" minOccurs="0" maxOccurs="1"/>
37 <!´´ address: rfc6351 xCard: vCard XML Representation ´´>
38 <xs:element name="address" minOccurs="0" maxOccurs="1">
39 <xs:complexType>
40 <xs:sequence>
41 <xs:any namespace="##other" processContents="lax" minOccurs="1" maxOccurs="unbounded"/>
42 </xs:sequence>
43 </xs:complexType>
44 </xs:element>
45 </xs:all>
46 <xs:attribute name="id" type="xs:anyURI" use="optional"/>
47 </xs:complexType>
48
49
50 <xs:complexType name="LifeTimeType">
51 <xs:sequence>
52 <xs:element name="start" type="xs:dateTime" minOccurs="0" maxOccurs="1"/>

57
 GFD-R-P.206 May 2013

53 <xs:element name="end" type="xs:dateTime" minOccurs="0" maxOccurs="1"/>

54 </xs:sequence>
55 </xs:complexType>
56
57
58 <xs:group name="Group">
59 <xs:choice>
60 <xs:element ref="nml:Topology"/>
61 <xs:element ref="nml:PortGroup"/>
62 <xs:element ref="nml:LinkGroup"/>
63 <xs:element ref="nml:BidirectionalPort"/>
64 <xs:element ref="nml:BidirectionalLink"/>
65 </xs:choice>
66 </xs:group>
67
68
69 <!´´ Topology ´´>
70
71
72 <xs:complexType name="TopologyRelationType">
73 <xs:choice>
74 <xs:element ref="nml:Port" minOccurs="1" maxOccurs="unbounded"/>
75 <xs:element ref="nml:PortGroup" minOccurs="1" maxOccurs="unbounded"/>
76 <xs:group ref="nml:Service" minOccurs="1" maxOccurs="unbounded"/>
77 <xs:element ref="nml:Topology" minOccurs="1" maxOccurs="unbounded"/>
78 </xs:choice>
79 <xs:attribute name="type" use="required">
80 <xs:simpleType>
81 <xs:restriction base="xs:string">
82 <xs:enumeration value="http://schemas.ogf.org/nml/2013/05/base#hasInboundPort"/>
83 <xs:enumeration value="http://schemas.ogf.org/nml/2013/05/base#hasOutboundPort"/>
84 <xs:enumeration value="http://schemas.ogf.org/nml/2013/05/base#hasService"/>
85 <xs:enumeration value="http://schemas.ogf.org/nml/2013/05/base#isAlias"/>
86 </xs:restriction>
87 </xs:simpleType>
88 </xs:attribute>
89 </xs:complexType>
90
91
92 <xs:group name="BaseTopologyContent">
93 <xs:sequence>
94 <xs:element ref="nml:Link" minOccurs="0" maxOccurs="unbounded"/>
95 <xs:element ref="nml:Port" minOccurs="0" maxOccurs="unbounded"/>
96 <xs:element ref="nml:Node" minOccurs="0" maxOccurs="unbounded"/>
97 <xs:group ref="nml:Service" minOccurs="0" maxOccurs="unbounded"/>
98 <xs:group ref="nml:Group" minOccurs="0" maxOccurs="unbounded"/>
99 <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
100 </xs:sequence>
101 </xs:group>
102
103
104 <xs:complexType name="TopologyType">
105 <xs:complexContent>
106 <xs:extension base="nml:NetworkObject">
107 <xs:sequence>
108 <xs:group ref="nml:BaseTopologyContent"/>
109 <xs:element name="Relation" type="nml:TopologyRelationType" minOccurs="0" maxOccurs="unbounded"/>
110 </xs:sequence>
111 </xs:extension>
112 </xs:complexContent>

58
 GFD-R-P.206 May 2013

113 </xs:complexType>
114
115
116 <xs:element name="Topology" type="nml:TopologyType"/>
117
118
119 <!´´ Link ´´>
120
121
122 <xs:complexType name="LinkRelationType">
123 <xs:sequence>
124 <xs:element ref="nml:Link" minOccurs="1" maxOccurs="unbounded"/>
125 </xs:sequence>
126 <xs:attribute name="type" use="required">
127 <xs:simpleType>
128 <xs:restriction base="xs:string">
129 <xs:enumeration value="http://schemas.ogf.org/nml/2013/05/base#isAlias"/>
130 <xs:enumeration value="http://schemas.ogf.org/nml/2013/05/base#isSerialCompoundLink"/>
131 <xs:enumeration value="http://schemas.ogf.org/nml/2013/05/base#next"/>
132 </xs:restriction>
133 </xs:simpleType>
134 </xs:attribute>
135 </xs:complexType>
136
137
138 <xs:group name="BaseLinkContent">
139 <xs:sequence>
140 <xs:element ref="nml:Label" minOccurs="0"/>
141 <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
142 </xs:sequence>
143 </xs:group>
144
145
146 <xs:complexType name="LinkType">
147 <xs:complexContent>
148 <xs:extension base="nml:NetworkObject">
149 <xs:sequence>
150 <xs:group ref="nml:BaseLinkContent"/>
151 <xs:element name="Relation" type="nml:LinkRelationType" minOccurs="0" maxOccurs="unbounded"/>
152 </xs:sequence>
153 <xs:attribute name="encoding" type="xs:anyURI" use="optional"/>
154 <xs:attribute name="noReturnTraffic" type="xs:boolean" use="optional"/>
155 </xs:extension>
156 </xs:complexContent>
157 </xs:complexType>
158
159
160 <xs:element name="Link" type="nml:LinkType"/>
161
162
163 <!´´ Port ´´>
164
165
166 <xs:complexType name="PortRelationType">
167 <xs:choice>
168 <xs:element ref="nml:Link" minOccurs="1" maxOccurs="unbounded"/>
169 <xs:element ref="nml:Port" minOccurs="1" maxOccurs="unbounded"/>
170 <xs:group ref="nml:Service" minOccurs="1" maxOccurs="unbounded"/>
171 </xs:choice>
172 <xs:attribute name="type" use="required">

59
 GFD-R-P.206 May 2013

173 <xs:simpleType>
174 <xs:restriction base="xs:string">
175 <xs:enumeration value="http://schemas.ogf.org/nml/2013/05/base#hasService"/>
176 <xs:enumeration value="http://schemas.ogf.org/nml/2013/05/base#isAlias"/>
177 <xs:enumeration value="http://schemas.ogf.org/nml/2013/05/base#isSink"/>
178 <xs:enumeration value="http://schemas.ogf.org/nml/2013/05/base#isSource"/>
179 </xs:restriction>
180 </xs:simpleType>
181 </xs:attribute>
182 </xs:complexType>
183
184
185 <xs:group name="BasePortContent">
186 <xs:sequence>
187 <xs:element ref="nml:Label" minOccurs="0" maxOccurs="1"/>
188 <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
189 </xs:sequence>
190 </xs:group>
191
192
193 <xs:complexType name="PortType">
194 <xs:complexContent>
195 <xs:extension base="nml:NetworkObject">
196 <xs:sequence>
197 <xs:group ref="nml:BasePortContent"/>
198 <xs:element name="Relation" type="nml:PortRelationType" minOccurs="0" maxOccurs="unbounded"/>
199 </xs:sequence>
200 <xs:attribute name="encoding" type="xs:anyURI" use="optional"/>
201 </xs:extension>
202 </xs:complexContent>
203 </xs:complexType>
204
205
206 <xs:element name="Port" type="nml:PortType"/>
207
208
209 <!´´ Node ´´>
210
211
212 <xs:complexType name="NodeRelationType">
213 <xs:choice>
214 <xs:element ref="nml:Node" minOccurs="1" maxOccurs="unbounded"/>
215 <xs:element ref="nml:Port" minOccurs="1" maxOccurs="unbounded"/>
216 <xs:element ref="nml:PortGroup" minOccurs="1" maxOccurs="unbounded"/>
217 <xs:element ref="nml:SwitchingService" minOccurs="1" maxOccurs="unbounded"/>
218 </xs:choice>
219 <xs:attribute name="type" use="required">
220 <xs:simpleType>
221 <xs:restriction base="xs:string">
222 <xs:enumeration value="http://schemas.ogf.org/nml/2013/05/base#hasInboundPort"/>
223 <xs:enumeration value="http://schemas.ogf.org/nml/2013/05/base#hasOutboundPort"/>
224 <xs:enumeration value="http://schemas.ogf.org/nml/2013/05/base#hasService"/>
225 <xs:enumeration value="http://schemas.ogf.org/nml/2013/05/base#isAlias"/>
226 </xs:restriction>
227 </xs:simpleType>
228 </xs:attribute>
229 </xs:complexType>
230
231
232 <xs:complexType name="NodeType">

60
 GFD-R-P.206 May 2013

233 <xs:complexContent>
234 <xs:extension base="nml:NetworkObject">
235 <xs:sequence>
236 <xs:element ref="nml:Node" minOccurs="0" maxOccurs="unbounded"/>
237 <xs:element name="Relation" type="nml:NodeRelationType" minOccurs="0" maxOccurs="unbounded"/>
238 <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
239 </xs:sequence>
240 </xs:extension>
241 </xs:complexContent>
242 </xs:complexType>
243
244
245 <xs:element name="Node" type="nml:NodeType"/>
246
247
248 <!´´ Service ´´>
249
250
251 <xs:group name="Service">
252 <xs:choice>
253 <xs:element ref="nml:SwitchingService"/>
254 <xs:element ref="nml:AdaptationService"/>
255 <xs:element ref="nml:DeadaptationService"/>
256 </xs:choice>
257 </xs:group>
258
259
260 <!´´ SwitchingService ´´>
261
262
263 <xs:complexType name="SwitchingServiceRelationType">
264 <xs:choice>
265 <xs:element ref="nml:Port" minOccurs="1" maxOccurs="unbounded"/>
266 <xs:element ref="nml:PortGroup" minOccurs="1" maxOccurs="unbounded"/>
267 <xs:element ref="nml:SwitchingService" minOccurs="1" maxOccurs="unbounded"/>
268 <xs:element ref="nml:Link" minOccurs="1" maxOccurs="unbounded"/>
269 <xs:element ref="nml:LinkGroup" minOccurs="1" maxOccurs="unbounded"/>
270 </xs:choice>
271 <xs:attribute name="type" use="required">
272 <xs:simpleType>
273 <xs:restriction base="xs:string">
274 <xs:enumeration value="http://schemas.ogf.org/nml/2013/05/base#hasInboundPort"/>
275 <xs:enumeration value="http://schemas.ogf.org/nml/2013/05/base#hasOutboundPort"/>
276 <xs:enumeration value="http://schemas.ogf.org/nml/2013/05/base#isAlias"/>
277 <xs:enumeration value="http://schemas.ogf.org/nml/2013/05/base#providesLink"/>
278 </xs:restriction>
279 </xs:simpleType>
280 </xs:attribute>
281 </xs:complexType>
282
283
284 <xs:complexType name="SwitchingServiceType">
285 <xs:complexContent>
286 <xs:extension base="nml:NetworkObject">
287 <xs:sequence>
288 <xs:element name="Relation" type="nml:SwitchingServiceRelationType" minOccurs="0" maxOccurs="unbounded
"/>
289 </xs:sequence>
290 <xs:attribute name="encoding" type="xs:anyURI" use="optional"/>
291 <xs:attribute name="labelSwapping" type="xs:boolean" use="optional"/>

61
 GFD-R-P.206 May 2013

292 </xs:extension>
293 </xs:complexContent>
294 </xs:complexType>
295
296
297 <xs:element name="SwitchingService" type="nml:SwitchingServiceType"/>
298
299
300 <!´´ AdaptationService ´´>
301
302
303 <xs:complexType name="AdaptationServiceRelationType">
304 <xs:choice>
305 <xs:element ref="nml:Port" minOccurs="1" maxOccurs="unbounded"/>
306 <xs:element ref="nml:PortGroup" minOccurs="1" maxOccurs="unbounded"/>
307 <xs:element ref="nml:AdaptationService" minOccurs="1" maxOccurs="unbounded"/>
308 </xs:choice>
309 <xs:attribute name="type" use="required">
310 <xs:simpleType>
311 <xs:restriction base="xs:string">
312 <xs:enumeration value="http://schemas.ogf.org/nml/2013/05/base#canProvidePort"/>
313 <xs:enumeration value="http://schemas.ogf.org/nml/2013/05/base#isAlias"/>
314 <xs:enumeration value="http://schemas.ogf.org/nml/2013/05/base#providesPort"/>
315 </xs:restriction>
316 </xs:simpleType>
317 </xs:attribute>
318 </xs:complexType>
319
320
321 <xs:complexType name="AdaptationServiceType">
322 <xs:complexContent>
323 <xs:extension base="nml:NetworkObject">
324 <xs:sequence>
325 <xs:element name="Relation" type="nml:AdaptationServiceRelationType" minOccurs="0" maxOccurs="
unbounded"/>
326 </xs:sequence>
327 <xs:attribute name="adaptationFunction" type="xs:anyURI" use="optional"/>
328 </xs:extension>
329 </xs:complexContent>
330 </xs:complexType>
331
332
333 <xs:element name="AdaptationService" type="nml:AdaptationServiceType"/>
334
335
336 <!´´ DeadaptationService ´´>
337
338
339 <xs:complexType name="DeadaptationServiceRelationType">
340 <xs:choice>
341 <xs:element ref="nml:Port" minOccurs="1" maxOccurs="unbounded"/>
342 <xs:element ref="nml:PortGroup" minOccurs="1" maxOccurs="unbounded"/>
343 <xs:element ref="nml:DeadaptationService" minOccurs="1" maxOccurs="unbounded"/>
344 </xs:choice>
345 <xs:attribute name="type" use="required">
346 <xs:simpleType>
347 <xs:restriction base="xs:string">
348 <xs:enumeration value="http://schemas.ogf.org/nml/2013/05/base#canProvidePort"/>
349 <xs:enumeration value="http://schemas.ogf.org/nml/2013/05/base#isAlias"/>
350 <xs:enumeration value="http://schemas.ogf.org/nml/2013/05/base#providesPort"/>

62
 GFD-R-P.206 May 2013

351 </xs:restriction>
352 </xs:simpleType>
353 </xs:attribute>
354 </xs:complexType>
355
356
357 <xs:complexType name="DeadaptationServiceType">
358 <xs:complexContent>
359 <xs:extension base="nml:NetworkObject">
360 <xs:sequence>
361 <xs:element name="Relation" type="nml:DeadaptationServiceRelationType" minOccurs="0" maxOccurs="
unbounded"/>
362 </xs:sequence>
363 <xs:attribute name="adaptationFunction" type="xs:anyURI" use="optional"/>
364 </xs:extension>
365 </xs:complexContent>
366 </xs:complexType>
367
368
369 <xs:element name="DeadaptationService" type="nml:DeadaptationServiceType"/>
370
371
372 <!´´ Label ´´>
373
374
375 <xs:complexType name="LabelType">
376 <xs:simpleContent>
377 <xs:extension base="xs:string">
378 <xs:attribute name="labeltype" type="xs:anyURI" use="required"/>
379 </xs:extension>
380 </xs:simpleContent>
381 </xs:complexType>
382
383
384 <xs:element name="Label" type="nml:LabelType"/>
385
386
387 <!´´ LinkGroup ´´>
388
389
390 <xs:complexType name="LinkGroupRelationType">
391 <xs:sequence>
392 <xs:element ref="nml:LinkGroup" minOccurs="1" maxOccurs="unbounded"/>
393 </xs:sequence>
394 <xs:attribute name="type" use="required">
395 <xs:simpleType>
396 <xs:restriction base="xs:string">
397 <xs:enumeration value="http://schemas.ogf.org/nml/2013/05/base#isAlias"/>
398 <xs:enumeration value="http://schemas.ogf.org/nml/2013/05/base#isSerialCompoundLink"/>
399 </xs:restriction>
400 </xs:simpleType>
401 </xs:attribute>
402 </xs:complexType>
403
404
405 <xs:group name="BaseLinkGroup">
406 <xs:sequence>
407 <xs:element ref="nml:LabelGroup" minOccurs="0" maxOccurs="unbounded"/>
408 <xs:element ref="nml:Link" minOccurs="0" maxOccurs="unbounded"/>
409 <xs:element ref="nml:LinkGroup" minOccurs="0" maxOccurs="unbounded"/>

63
 GFD-R-P.206 May 2013

410 </xs:sequence>
411 </xs:group>
412
413
414 <xs:complexType name="LinkGroupType">
415 <xs:complexContent>
416 <xs:extension base="nml:NetworkObject">
417 <xs:sequence>
418 <xs:group ref="nml:BaseLinkGroup"/>
419 <xs:element name="Relation" type="nml:LinkGroupRelationType" minOccurs="0" maxOccurs="unbounded"/>
420 </xs:sequence>
421 </xs:extension>
422 </xs:complexContent>
423 </xs:complexType>
424
425
426 <xs:element name="LinkGroup" type="nml:LinkGroupType"/>
427
428
429 <!´´ PortGroup ´´>
430
431
432 <xs:complexType name="PortGroupRelationType">
433 <xs:choice>
434 <xs:element ref="nml:PortGroup" minOccurs="1" maxOccurs="unbounded"/>
435 <xs:element ref="nml:LinkGroup" minOccurs="1" maxOccurs="unbounded"/>
436 </xs:choice>
437 <xs:attribute name="type" use="required">
438 <xs:simpleType>
439 <xs:restriction base="xs:string">
440 <xs:enumeration value="http://schemas.ogf.org/nml/2013/05/base#isAlias"/>
441 <xs:enumeration value="http://schemas.ogf.org/nml/2013/05/base#isSink"/>
442 <xs:enumeration value="http://schemas.ogf.org/nml/2013/05/base#isSource"/>
443 </xs:restriction>
444 </xs:simpleType>
445 </xs:attribute>
446 </xs:complexType>
447
448
449 <xs:group name="BasePortGroup">
450 <xs:sequence>
451 <xs:element ref="nml:LabelGroup" minOccurs="0" maxOccurs="unbounded"/>
452 <xs:element ref="nml:Port" minOccurs="0" maxOccurs="unbounded"/>
453 <xs:element ref="nml:PortGroup" minOccurs="0" maxOccurs="unbounded"/>
454 </xs:sequence>
455 </xs:group>
456
457
458 <xs:complexType name="PortGroupType">
459 <xs:complexContent>
460 <xs:extension base="nml:NetworkObject">
461 <xs:sequence>
462 <xs:group ref="nml:BasePortGroup"/>
463 <xs:element name="Relation" type="nml:PortGroupRelationType" minOccurs="0" maxOccurs="unbounded"/>
464 </xs:sequence>
465 <xs:attribute name="encoding" type="xs:anyURI" use="optional"/>
466 </xs:extension>
467 </xs:complexContent>
468 </xs:complexType>
469

64
 GFD-R-P.206 May 2013

470
471 <xs:element name="PortGroup" type="nml:PortGroupType"/>
472
473
474
475 <!´´ BidirectionalLink ´´>
476
477
478 <xs:group name="BaseBidirectionalLink">
479 <xs:choice>
480 <xs:sequence>
481 <xs:element ref="nml:Link"/>
482 <xs:element ref="nml:Link"/>
483 </xs:sequence>
484 <xs:sequence>
485 <xs:element ref="nml:LinkGroup"/>
486 <xs:element ref="nml:LinkGroup"/>
487 </xs:sequence>
488 </xs:choice>
489 </xs:group>
490
491
492 <xs:complexType name="BidirectionalLinkType">
493 <xs:complexContent>
494 <xs:extension base="nml:NetworkObject">
495 <xs:group ref="nml:BaseBidirectionalLink"/>
496 </xs:extension>
497 </xs:complexContent>
498 </xs:complexType>
499
500
501 <xs:element name="BidirectionalLink" type="nml:BidirectionalLinkType"/>
502
503
504 <!´´ BidirectionalPort ´´>
505
506
507 <xs:group name="BaseBidirectionalPort">
508 <xs:choice>
509 <xs:sequence>
510 <xs:element ref="nml:Port"/>
511 <xs:element ref="nml:Port"/>
512 </xs:sequence>
513 <xs:sequence>
514 <xs:element ref="nml:PortGroup"/>
515 <xs:element ref="nml:PortGroup"/>
516 </xs:sequence>
517 </xs:choice>
518 </xs:group>
519
520
521 <xs:complexType name="BidirectionalPortType">
522 <xs:complexContent>
523 <xs:extension base="nml:NetworkObject">
524 <xs:group ref="nml:BaseBidirectionalPort"/>
525 </xs:extension>
526 </xs:complexContent>
527 </xs:complexType>
528
529

65
 GFD-R-P.206 May 2013

530 <xs:element name="BidirectionalPort" type="nml:BidirectionalPortType"/>

531
532
533 <!´´ LabelGroup ´´>
534
535
536 <xs:complexType name="LabelGroupType">
537 <xs:simpleContent>
538 <xs:extension base="xs:string">
539 <xs:attribute name="labeltype" type="xs:anyURI" use="required"/>
540 </xs:extension>
541 </xs:simpleContent>
542 </xs:complexType>
543
544
545 <xs:element name="LabelGroup" type="nml:LabelGroupType"/>
546
547
548 </xs:schema>

66
 GFD-R-P.206 May 2013

Appendix B OWL Schema

This section describes the normative schema of the OWL syntax using the OWL ontology
definition below.
1 <?xml version="1.0"?>
2 <rdf:RDF xmlns="http://schemas.ogf.org/nml/2013/05/base#"
3 xml:base="http://schemas.ogf.org/nml/2013/05/base"
4 xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
5 xmlns:owl="http://www.w3.org/2002/07/owl#"
6 xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
7 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
8 xmlns:nml="http://schemas.ogf.org/nml/2013/05/base#">
9 <owl:Ontology rdf:about="http://schemas.ogf.org/nml/2013/05/base#">
10 <rdfs:label>NML Schema</rdfs:label>
11 </owl:Ontology>
12
13
14 <!´´
15 ///////////////////////////////////////////////////////////////////////////////////////
16 //
17 // Object Properties
18 //
19 ///////////////////////////////////////////////////////////////////////////////////////
20 ´´>
21
22
23 <!´´ http://schemas.ogf.org/nml/2013/05/base#adaptationFunction ´´>
24
25 <owl:ObjectProperty rdf:about="http://schemas.ogf.org/nml/2013/05/base#adaptationFunction">
26 <rdfs:domain>
27 <owl:Class>
28 <owl:unionOf rdf:parseType="Collection">
29 <rdf:Description rdf:about="http://schemas.ogf.org/nml/2013/05/base#AdaptationService"/>
30 <rdf:Description rdf:about="http://schemas.ogf.org/nml/2013/05/base#DeadaptationService"/>
31 </owl:unionOf>
32 </owl:Class>
33 </rdfs:domain>
34 </owl:ObjectProperty>
35
36
37 <!´´ http://schemas.ogf.org/nml/2013/05/base#address ´´>
38
39 <owl:ObjectProperty rdf:about="http://schemas.ogf.org/nml/2013/05/base#address">
40 <rdfs:domain rdf:resource="http://schemas.ogf.org/nml/2013/05/base#Location"/>
41 </owl:ObjectProperty>
42
43
44 <!´´ http://schemas.ogf.org/nml/2013/05/base#canProvidePort ´´>
45
46 <owl:ObjectProperty rdf:about="http://schemas.ogf.org/nml/2013/05/base#canProvidePort">
47 <rdfs:domain rdf:resource="http://schemas.ogf.org/nml/2013/05/base#Service"/>
48 <rdfs:range>
49 <owl:Class>
50 <owl:unionOf rdf:parseType="Collection">
51 <rdf:Description rdf:about="http://schemas.ogf.org/nml/2013/05/base#Port"/>
52 <rdf:Description rdf:about="http://schemas.ogf.org/nml/2013/05/base#PortGroup"/>

67
 GFD-R-P.206 May 2013

53 </owl:unionOf>
54 </owl:Class>
55 </rdfs:range>
56 </owl:ObjectProperty>
57
58
59 <!´´ http://schemas.ogf.org/nml/2013/05/base#encoding ´´>
60
61 <owl:ObjectProperty rdf:about="http://schemas.ogf.org/nml/2013/05/base#encoding">
62 <rdfs:domain>
63 <owl:Class>
64 <owl:unionOf rdf:parseType="Collection">
65 <rdf:Description rdf:about="http://schemas.ogf.org/nml/2013/05/base#Link"/>
66 <rdf:Description rdf:about="http://schemas.ogf.org/nml/2013/05/base#LinkGroup"/>
67 <rdf:Description rdf:about="http://schemas.ogf.org/nml/2013/05/base#Port"/>
68 <rdf:Description rdf:about="http://schemas.ogf.org/nml/2013/05/base#PortGroup"/>
69 <rdf:Description rdf:about="http://schemas.ogf.org/nml/2013/05/base#SwitchingService"/>
70 </owl:unionOf>
71 </owl:Class>
72 </rdfs:domain>
73 </owl:ObjectProperty>
74
75
76 <!´´ http://schemas.ogf.org/nml/2013/05/base#existsDuring ´´>
77
78 <owl:ObjectProperty rdf:about="http://schemas.ogf.org/nml/2013/05/base#existsDuring">
79 <rdfs:domain rdf:resource="http://schemas.ogf.org/nml/2013/05/base#NetworkObject"/>
80 <rdfs:range rdf:resource="http://schemas.ogf.org/nml/2013/05/base#Lifetime"/>
81 </owl:ObjectProperty>
82
83
84 <!´´ http://schemas.ogf.org/nml/2013/05/base#hasInboundPort ´´>
85
86 <owl:ObjectProperty rdf:about="http://schemas.ogf.org/nml/2013/05/base#hasInboundPort">
87 <rdfs:domain rdf:resource="http://schemas.ogf.org/nml/2013/05/base#NetworkObject"/>
88 <rdfs:range>
89 <owl:Class>
90 <owl:unionOf rdf:parseType="Collection">
91 <rdf:Description rdf:about="http://schemas.ogf.org/nml/2013/05/base#Port"/>
92 <rdf:Description rdf:about="http://schemas.ogf.org/nml/2013/05/base#PortGroup"/>
93 </owl:unionOf>
94 </owl:Class>
95 </rdfs:range>
96 </owl:ObjectProperty>
97
98
99 <!´´ http://schemas.ogf.org/nml/2013/05/base#hasLabel ´´>
100
101 <owl:ObjectProperty rdf:about="http://schemas.ogf.org/nml/2013/05/base#hasLabel">
102 <rdfs:domain>
103 <owl:Class>
104 <owl:unionOf rdf:parseType="Collection">
105 <rdf:Description rdf:about="http://schemas.ogf.org/nml/2013/05/base#Link"/>
106 <rdf:Description rdf:about="http://schemas.ogf.org/nml/2013/05/base#Port"/>
107 </owl:unionOf>
108 </owl:Class>
109 </rdfs:domain>
110 <rdfs:range rdf:resource="http://schemas.ogf.org/nml/2013/05/base#Label"/>
111 </owl:ObjectProperty>
112

68
 GFD-R-P.206 May 2013

113
114 <!´´ http://schemas.ogf.org/nml/2013/05/base#hasLabelGroup ´´>
115
116 <owl:ObjectProperty rdf:about="http://schemas.ogf.org/nml/2013/05/base#hasLabelGroup">
117 <rdfs:domain>
118 <owl:Class>
119 <owl:unionOf rdf:parseType="Collection">
120 <rdf:Description rdf:about="http://schemas.ogf.org/nml/2013/05/base#LinkGroup"/>
121 <rdf:Description rdf:about="http://schemas.ogf.org/nml/2013/05/base#PortGroup"/>
122 </owl:unionOf>
123 </owl:Class>
124 </rdfs:domain>
125 <rdfs:range rdf:resource="http://schemas.ogf.org/nml/2013/05/base#LabelGroup"/>
126 </owl:ObjectProperty>
127
128
129 <!´´ http://schemas.ogf.org/nml/2013/05/base#hasLink ´´>
130
131 <owl:ObjectProperty rdf:about="http://schemas.ogf.org/nml/2013/05/base#hasLink">
132 <rdfs:domain rdf:resource="http://schemas.ogf.org/nml/2013/05/base#Group"/>
133 <rdfs:range>
134 <owl:Class>
135 <owl:unionOf rdf:parseType="Collection">
136 <rdf:Description rdf:about="http://schemas.ogf.org/nml/2013/05/base#Link"/>
137 <rdf:Description rdf:about="http://schemas.ogf.org/nml/2013/05/base#LinkGroup"/>
138 </owl:unionOf>
139 </owl:Class>
140 </rdfs:range>
141 </owl:ObjectProperty>
142
143
144 <!´´ http://schemas.ogf.org/nml/2013/05/base#hasNode ´´>
145
146 <owl:ObjectProperty rdf:about="http://schemas.ogf.org/nml/2013/05/base#hasNode">
147 <rdfs:domain rdf:resource="http://schemas.ogf.org/nml/2013/05/base#NetworkObject"/>
148 <rdfs:range rdf:resource="http://schemas.ogf.org/nml/2013/05/base#Node"/>
149 </owl:ObjectProperty>
150
151
152 <!´´ http://schemas.ogf.org/nml/2013/05/base#hasOutboundPort ´´>
153
154 <owl:ObjectProperty rdf:about="http://schemas.ogf.org/nml/2013/05/base#hasOutboundPort">
155 <rdfs:domain rdf:resource="http://schemas.ogf.org/nml/2013/05/base#NetworkObject"/>
156 <rdfs:range>
157 <owl:Class>
158 <owl:unionOf rdf:parseType="Collection">
159 <rdf:Description rdf:about="http://schemas.ogf.org/nml/2013/05/base#Port"/>
160 <rdf:Description rdf:about="http://schemas.ogf.org/nml/2013/05/base#PortGroup"/>
161 </owl:unionOf>
162 </owl:Class>
163 </rdfs:range>
164 </owl:ObjectProperty>
165
166
167 <!´´ http://schemas.ogf.org/nml/2013/05/base#hasPort ´´>
168
169 <owl:ObjectProperty rdf:about="http://schemas.ogf.org/nml/2013/05/base#hasPort">
170 <rdfs:domain rdf:resource="http://schemas.ogf.org/nml/2013/05/base#Group"/>
171 <rdfs:range rdf:resource="http://schemas.ogf.org/nml/2013/05/base#Port"/>
172 </owl:ObjectProperty>

69
 GFD-R-P.206 May 2013

173
174
175 <!´´ http://schemas.ogf.org/nml/2013/05/base#hasService ´´>
176
177 <owl:ObjectProperty rdf:about="http://schemas.ogf.org/nml/2013/05/base#hasService">
178 <rdfs:domain rdf:resource="http://schemas.ogf.org/nml/2013/05/base#NetworkObject"/>
179 <rdfs:range rdf:resource="http://schemas.ogf.org/nml/2013/05/base#Service"/>
180 </owl:ObjectProperty>
181
182
183 <!´´ http://schemas.ogf.org/nml/2013/05/base#hasTopology ´´>
184
185 <owl:ObjectProperty rdf:about="http://schemas.ogf.org/nml/2013/05/base#hasTopology">
186 <rdfs:domain rdf:resource="http://schemas.ogf.org/nml/2013/05/base#NetworkObject"/>
187 <rdfs:range rdf:resource="http://schemas.ogf.org/nml/2013/05/base#Topology"/>
188 </owl:ObjectProperty>
189
190
191 <!´´ http://schemas.ogf.org/nml/2013/05/base#implementedBy ´´>
192
193 <owl:ObjectProperty rdf:about="http://schemas.ogf.org/nml/2013/05/base#implementedBy">
194 <rdfs:domain rdf:resource="http://schemas.ogf.org/nml/2013/05/base#NetworkObject"/>
195 <rdfs:range rdf:resource="http://schemas.ogf.org/nml/2013/05/base#NetworkObject"/>
196 </owl:ObjectProperty>
197
198
199 <!´´ http://schemas.ogf.org/nml/2013/05/base#isAlias ´´>
200
201 <owl:ObjectProperty rdf:about="http://schemas.ogf.org/nml/2013/05/base#isAlias">
202 <rdfs:domain rdf:resource="http://schemas.ogf.org/nml/2013/05/base#NetworkObject"/>
203 <rdfs:range rdf:resource="http://schemas.ogf.org/nml/2013/05/base#NetworkObject"/>
204 </owl:ObjectProperty>
205
206
207 <!´´ http://schemas.ogf.org/nml/2013/05/base#isSerialCompoundLink ´´>
208
209 <owl:ObjectProperty rdf:about="http://schemas.ogf.org/nml/2013/05/base#isSerialCompoundLink">
210 <rdfs:domain>
211 <owl:Class>
212 <owl:unionOf rdf:parseType="Collection">
213 <rdf:Description rdf:about="http://schemas.ogf.org/nml/2013/05/base#Link"/>
214 <rdf:Description rdf:about="http://schemas.ogf.org/nml/2013/05/base#LinkGroup"/>
215 </owl:unionOf>
216 </owl:Class>
217 </rdfs:domain>
218 <rdfs:range rdf:resource="http://schemas.ogf.org/nml/2013/05/base#ListItem"/>
219 </owl:ObjectProperty>
220
221
222 <!´´ http://schemas.ogf.org/nml/2013/05/base#isSink ´´>
223
224 <owl:ObjectProperty rdf:about="http://schemas.ogf.org/nml/2013/05/base#isSink">
225 <rdfs:domain rdf:resource="http://schemas.ogf.org/nml/2013/05/base#NetworkObject"/>
226 <rdfs:range>
227 <owl:Class>
228 <owl:unionOf rdf:parseType="Collection">
229 <rdf:Description rdf:about="http://schemas.ogf.org/nml/2013/05/base#Link"/>
230 <rdf:Description rdf:about="http://schemas.ogf.org/nml/2013/05/base#LinkGroup"/>
231 </owl:unionOf>
232 </owl:Class>

70
 GFD-R-P.206 May 2013

233 </rdfs:range>
234 </owl:ObjectProperty>
235
236
237 <!´´ http://schemas.ogf.org/nml/2013/05/base#isSource ´´>
238
239 <owl:ObjectProperty rdf:about="http://schemas.ogf.org/nml/2013/05/base#isSource">
240 <rdfs:domain rdf:resource="http://schemas.ogf.org/nml/2013/05/base#NetworkObject"/>
241 <rdfs:range>
242 <owl:Class>
243 <owl:unionOf rdf:parseType="Collection">
244 <rdf:Description rdf:about="http://schemas.ogf.org/nml/2013/05/base#Link"/>
245 <rdf:Description rdf:about="http://schemas.ogf.org/nml/2013/05/base#LinkGroup"/>
246 </owl:unionOf>
247 </owl:Class>
248 </rdfs:range>
249 </owl:ObjectProperty>
250
251
252 <!´´ http://schemas.ogf.org/nml/2013/05/base#item ´´>
253
254 <owl:ObjectProperty rdf:about="http://schemas.ogf.org/nml/2013/05/base#item">
255 <rdfs:domain rdf:resource="http://schemas.ogf.org/nml/2013/05/base#ListItem"/>
256 </owl:ObjectProperty>
257
258
259 <!´´ http://schemas.ogf.org/nml/2013/05/base#labeltype ´´>
260
261 <owl:ObjectProperty rdf:about="http://schemas.ogf.org/nml/2013/05/base#labeltype">
262 <rdfs:domain>
263 <owl:Class>
264 <owl:unionOf rdf:parseType="Collection">
265 <rdf:Description rdf:about="http://schemas.ogf.org/nml/2013/05/base#Label"/>
266 <rdf:Description rdf:about="http://schemas.ogf.org/nml/2013/05/base#LabelGroup"/>
267 </owl:unionOf>
268 </owl:Class>
269 </rdfs:domain>
270 </owl:ObjectProperty>
271
272
273 <!´´ http://schemas.ogf.org/nml/2013/05/base#locatedAt ´´>
274
275 <owl:ObjectProperty rdf:about="http://schemas.ogf.org/nml/2013/05/base#locatedAt">
276 <rdfs:domain rdf:resource="http://schemas.ogf.org/nml/2013/05/base#NetworkObject"/>
277 <rdfs:range rdf:resource="http://schemas.ogf.org/nml/2013/05/base#Location"/>
278 </owl:ObjectProperty>
279
280
281 <!´´ http://schemas.ogf.org/nml/2013/05/base#next ´´>
282
283 <owl:ObjectProperty rdf:about="http://schemas.ogf.org/nml/2013/05/base#next">
284 <rdfs:domain rdf:resource="http://schemas.ogf.org/nml/2013/05/base#ListItem"/>
285 <rdfs:range rdf:resource="http://schemas.ogf.org/nml/2013/05/base#ListItem"/>
286 </owl:ObjectProperty>
287
288
289 <!´´ http://schemas.ogf.org/nml/2013/05/base#providesLink ´´>
290
291 <owl:ObjectProperty rdf:about="http://schemas.ogf.org/nml/2013/05/base#providesLink">
292 <rdfs:domain rdf:resource="http://schemas.ogf.org/nml/2013/05/base#Service"/>

71
 GFD-R-P.206 May 2013

293 <rdfs:range>
294 <owl:Class>
295 <owl:unionOf rdf:parseType="Collection">
296 <rdf:Description rdf:about="http://schemas.ogf.org/nml/2013/05/base#Link"/>
297 <rdf:Description rdf:about="http://schemas.ogf.org/nml/2013/05/base#LinkGroup"/>
298 </owl:unionOf>
299 </owl:Class>
300 </rdfs:range>
301 </owl:ObjectProperty>
302
303
304 <!´´ http://schemas.ogf.org/nml/2013/05/base#providesPort ´´>
305
306 <owl:ObjectProperty rdf:about="http://schemas.ogf.org/nml/2013/05/base#providesPort">
307 <rdfs:domain rdf:resource="http://schemas.ogf.org/nml/2013/05/base#Service"/>
308 <rdfs:range>
309 <owl:Class>
310 <owl:unionOf rdf:parseType="Collection">
311 <rdf:Description rdf:about="http://schemas.ogf.org/nml/2013/05/base#Port"/>
312 <rdf:Description rdf:about="http://schemas.ogf.org/nml/2013/05/base#PortGroup"/>
313 </owl:unionOf>
314 </owl:Class>
315 </rdfs:range>
316 </owl:ObjectProperty>
317
318
319 <!´´
320 ///////////////////////////////////////////////////////////////////////////////////////
321 //
322 // Data properties
323 //
324 ///////////////////////////////////////////////////////////////////////////////////////
325 ´´>
326
327
328 <!´´ http://schemas.ogf.org/nml/2013/05/base#alt ´´>
329
330 <owl:DatatypeProperty rdf:about="http://schemas.ogf.org/nml/2013/05/base#alt">
331 <rdfs:domain rdf:resource="http://schemas.ogf.org/nml/2013/05/base#Location"/>
332 <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#float"/>
333 </owl:DatatypeProperty>
334
335
336 <!´´ http://schemas.ogf.org/nml/2013/05/base#end ´´>
337
338 <owl:DatatypeProperty rdf:about="http://schemas.ogf.org/nml/2013/05/base#end">
339 <rdfs:domain rdf:resource="http://schemas.ogf.org/nml/2013/05/base#Lifetime"/>
340 <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#dateTime"/>
341 </owl:DatatypeProperty>
342
343
344 <!´´ http://schemas.ogf.org/nml/2013/05/base#labelSwapping ´´>
345
346 <owl:DatatypeProperty rdf:about="http://schemas.ogf.org/nml/2013/05/base#labelSwapping">
347 <rdfs:domain rdf:resource="http://schemas.ogf.org/nml/2013/05/base#SwitchingService"/>
348 <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#boolean"/>
349 </owl:DatatypeProperty>
350
351
352 <!´´ http://schemas.ogf.org/nml/2013/05/base#lat ´´>

72
 GFD-R-P.206 May 2013

353
354 <owl:DatatypeProperty rdf:about="http://schemas.ogf.org/nml/2013/05/base#lat">
355 <rdfs:domain rdf:resource="http://schemas.ogf.org/nml/2013/05/base#Location"/>
356 <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#float"/>
357 </owl:DatatypeProperty>
358
359
360 <!´´ http://schemas.ogf.org/nml/2013/05/base#long ´´>
361
362 <owl:DatatypeProperty rdf:about="http://schemas.ogf.org/nml/2013/05/base#long">
363 <rdfs:domain rdf:resource="http://schemas.ogf.org/nml/2013/05/base#Location"/>
364 <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#float"/>
365 </owl:DatatypeProperty>
366
367
368 <!´´ http://schemas.ogf.org/nml/2013/05/base#name ´´>
369
370 <owl:DatatypeProperty rdf:about="http://schemas.ogf.org/nml/2013/05/base#name">
371 <rdfs:domain>
372 <owl:Class>
373 <owl:unionOf rdf:parseType="Collection">
374 <rdf:Description rdf:about="http://schemas.ogf.org/nml/2013/05/base#Location"/>
375 <rdf:Description rdf:about="http://schemas.ogf.org/nml/2013/05/base#NetworkObject"/>
376 </owl:unionOf>
377 </owl:Class>
378 </rdfs:domain>
379 <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>
380 </owl:DatatypeProperty>
381
382
383 <!´´ http://schemas.ogf.org/nml/2013/05/base#noReturnTraffic ´´>
384
385 <owl:DatatypeProperty rdf:about="http://schemas.ogf.org/nml/2013/05/base#noReturnTraffic">
386 <rdfs:domain rdf:resource="http://schemas.ogf.org/nml/2013/05/base#Link"/>
387 <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#boolean"/>
388 </owl:DatatypeProperty>
389
390
391 <!´´ http://schemas.ogf.org/nml/2013/05/base#parameter ´´>
392
393 <owl:DatatypeProperty rdf:about="http://schemas.ogf.org/nml/2013/05/base#parameter">
394 <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>
395 </owl:DatatypeProperty>
396
397
398 <!´´ http://schemas.ogf.org/nml/2013/05/base#start ´´>
399
400 <owl:DatatypeProperty rdf:about="http://schemas.ogf.org/nml/2013/05/base#start">
401 <rdfs:domain rdf:resource="http://schemas.ogf.org/nml/2013/05/base#Lifetime"/>
402 <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#dateTime"/>
403 </owl:DatatypeProperty>
404
405
406 <!´´ http://schemas.ogf.org/nml/2013/05/base#unlocode ´´>
407
408 <owl:DatatypeProperty rdf:about="http://schemas.ogf.org/nml/2013/05/base#unlocode">
409 <rdfs:domain rdf:resource="http://schemas.ogf.org/nml/2013/05/base#Location"/>
410 <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>
411 </owl:DatatypeProperty>
412

73
 GFD-R-P.206 May 2013

413
414 <!´´ http://schemas.ogf.org/nml/2013/05/base#value ´´>
415
416 <owl:DatatypeProperty rdf:about="http://schemas.ogf.org/nml/2013/05/base#value">
417 <rdfs:domain rdf:resource="http://schemas.ogf.org/nml/2013/05/base#Label"/>
418 <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>
419 </owl:DatatypeProperty>
420
421
422 <!´´ http://schemas.ogf.org/nml/2013/05/base#values ´´>
423
424 <owl:DatatypeProperty rdf:about="http://schemas.ogf.org/nml/2013/05/base#values">
425 <rdfs:domain rdf:resource="http://schemas.ogf.org/nml/2013/05/base#LabelGroup"/>
426 <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>
427 </owl:DatatypeProperty>
428
429
430 <!´´ http://schemas.ogf.org/nml/2013/05/base#version ´´>
431
432 <owl:DatatypeProperty rdf:about="http://schemas.ogf.org/nml/2013/05/base#version">
433 <rdfs:domain rdf:resource="http://schemas.ogf.org/nml/2013/05/base#NetworkObject"/>
434 <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#dateTime"/>
435 </owl:DatatypeProperty>
436
437
438 <!´´
439 ///////////////////////////////////////////////////////////////////////////////////////
440 //
441 // Classes
442 //
443 ///////////////////////////////////////////////////////////////////////////////////////
444 ´´>
445
446
447
448 <!´´ http://schemas.ogf.org/nml/2013/05/base#AdaptationService ´´>
449
450 <owl:Class rdf:about="http://schemas.ogf.org/nml/2013/05/base#AdaptationService">
451 <rdfs:subClassOf rdf:resource="http://schemas.ogf.org/nml/2013/05/base#Service"/>
452 </owl:Class>
453
454
455 <!´´ http://schemas.ogf.org/nml/2013/05/base#BidirectionalLink ´´>
456
457 <owl:Class rdf:about="http://schemas.ogf.org/nml/2013/05/base#BidirectionalLink">
458 <rdfs:subClassOf rdf:resource="http://schemas.ogf.org/nml/2013/05/base#Group"/>
459 </owl:Class>
460
461
462 <!´´ http://schemas.ogf.org/nml/2013/05/base#BidirectionalPort ´´>
463
464 <owl:Class rdf:about="http://schemas.ogf.org/nml/2013/05/base#BidirectionalPort">
465 <rdfs:subClassOf rdf:resource="http://schemas.ogf.org/nml/2013/05/base#Group"/>
466 </owl:Class>
467
468
469 <!´´ http://schemas.ogf.org/nml/2013/05/base#DeadaptationService ´´>
470
471 <owl:Class rdf:about="http://schemas.ogf.org/nml/2013/05/base#DeadaptationService">
472 <rdfs:subClassOf rdf:resource="http://schemas.ogf.org/nml/2013/05/base#Service"/>

74
 GFD-R-P.206 May 2013

473 </owl:Class>
474
475
476 <!´´ http://schemas.ogf.org/nml/2013/05/base#Group ´´>
477
478 <owl:Class rdf:about="http://schemas.ogf.org/nml/2013/05/base#Group">
479 <rdfs:subClassOf rdf:resource="http://schemas.ogf.org/nml/2013/05/base#NetworkObject"/>
480 </owl:Class>
481
482
483 <!´´ http://schemas.ogf.org/nml/2013/05/base#Label ´´>
484
485 <owl:Class rdf:about="http://schemas.ogf.org/nml/2013/05/base#Label"/>
486
487
488 <!´´ http://schemas.ogf.org/nml/2013/05/base#LabelGroup ´´>
489
490 <owl:Class rdf:about="http://schemas.ogf.org/nml/2013/05/base#LabelGroup">
491 <rdfs:subClassOf rdf:resource="http://www.w3.org/2002/07/owl#Thing"/>
492 </owl:Class>
493
494
495 <!´´ http://schemas.ogf.org/nml/2013/05/base#Lifetime ´´>
496
497 <owl:Class rdf:about="http://schemas.ogf.org/nml/2013/05/base#Lifetime"/>
498
499
500 <!´´ http://schemas.ogf.org/nml/2013/05/base#Link ´´>
501
502 <owl:Class rdf:about="http://schemas.ogf.org/nml/2013/05/base#Link">
503 <rdfs:subClassOf rdf:resource="http://schemas.ogf.org/nml/2013/05/base#NetworkObject"/>
504 </owl:Class>
505
506
507 <!´´ http://schemas.ogf.org/nml/2013/05/base#LinkGroup ´´>
508
509 <owl:Class rdf:about="http://schemas.ogf.org/nml/2013/05/base#LinkGroup">
510 <rdfs:subClassOf rdf:resource="http://schemas.ogf.org/nml/2013/05/base#Group"/>
511 </owl:Class>
512
513
514 <!´´ http://schemas.ogf.org/nml/2013/05/base#ListItem ´´>
515
516 <owl:Class rdf:about="http://schemas.ogf.org/nml/2013/05/base#ListItem">
517 <rdfs:subClassOf rdf:resource="http://www.w3.org/2002/07/owl#Thing"/>
518 </owl:Class>
519
520
521 <!´´ http://schemas.ogf.org/nml/2013/05/base#Location ´´>
522
523 <owl:Class rdf:about="http://schemas.ogf.org/nml/2013/05/base#Location">
524 <rdfs:subClassOf rdf:resource="http://www.w3.org/2002/07/owl#Thing"/>
525 </owl:Class>
526
527
528 <!´´ http://schemas.ogf.org/nml/2013/05/base#NetworkObject ´´>
529
530 <owl:Class rdf:about="http://schemas.ogf.org/nml/2013/05/base#NetworkObject"/>
531
532

75
 GFD-R-P.206 May 2013

533 <!´´ http://schemas.ogf.org/nml/2013/05/base#Node ´´>

534
535 <owl:Class rdf:about="http://schemas.ogf.org/nml/2013/05/base#Node">
536 <rdfs:subClassOf rdf:resource="http://schemas.ogf.org/nml/2013/05/base#NetworkObject"/>
537 </owl:Class>
538
539
540 <!´´ http://schemas.ogf.org/nml/2013/05/base#Port ´´>
541
542 <owl:Class rdf:about="http://schemas.ogf.org/nml/2013/05/base#Port">
543 <rdfs:subClassOf rdf:resource="http://schemas.ogf.org/nml/2013/05/base#NetworkObject"/>
544 </owl:Class>
545
546
547 <!´´ http://schemas.ogf.org/nml/2013/05/base#PortGroup ´´>
548
549 <owl:Class rdf:about="http://schemas.ogf.org/nml/2013/05/base#PortGroup">
550 <rdfs:subClassOf rdf:resource="http://schemas.ogf.org/nml/2013/05/base#Group"/>
551 </owl:Class>
552
553
554 <!´´ http://schemas.ogf.org/nml/2013/05/base#Service ´´>
555
556 <owl:Class rdf:about="http://schemas.ogf.org/nml/2013/05/base#Service">
557 <rdfs:subClassOf rdf:resource="http://schemas.ogf.org/nml/2013/05/base#NetworkObject"/>
558 </owl:Class>
559
560
561 <!´´ http://schemas.ogf.org/nml/2013/05/base#SwitchingService ´´>
562
563 <owl:Class rdf:about="http://schemas.ogf.org/nml/2013/05/base#SwitchingService">
564 <rdfs:subClassOf rdf:resource="http://schemas.ogf.org/nml/2013/05/base#Service"/>
565 </owl:Class>
566
567
568 <!´´ http://schemas.ogf.org/nml/2013/05/base#Topology ´´>
569
570 <owl:Class rdf:about="http://schemas.ogf.org/nml/2013/05/base#Topology">
571 <rdfs:subClassOf rdf:resource="http://schemas.ogf.org/nml/2013/05/base#Group"/>
572 </owl:Class>
573 </rdf:RDF>

76
GFD-R-P.206 May 2013

Appendix C Relation to G.800

This section describes the relation between terms defined in this recommendation and those
defined in the ITU-T G.800 recommendation [G.800].
NML Term G.800 Term
Port Unidirectional Port
Link Either Link Connection or Network Connection
SwitchingService Subnetwork
AdaptationService Combined Adaptation Function and Termination Function
BidirectionalPort Port
Label Resource label

77
GFD-R-P.206 May 2013

References
Normative References
[GFD.202] Freek Dijkstra, and Jeroen van der Ham. A URN Namespace for Network Re-
sources. GFD 202 (Community Practise), June 2013. URL http://www.ogf.org/
documents/GFD.202.pdf.

[ISO 8601] Data elements and interchange formats – Information interchange – Repre-
sentation of dates and times. ISO 8601:2004 (Third edition), December 2004. Sec-
tion 4.3.2 (a), Complete representations of a date and time. Calendar date in ba-
sic format. URL http://www.iso.org/iso/home/store/catalogue_ics/catalogue_
detail_ics.htm?csnumber=40874.

[G.800] Unified functional architecture of transport networks. ITU-T Recommendation

G.800, February 2012. URL http://www.itu.int/rec/T-REC-G.800/.

[RDF-XML] Dave Beckett (editor) RDF/XML Syntax Specification (Revised) W3C Recom-
mendation 10 February 2004. URL http://www.w3.org/TR/rdf-syntax-grammar/.

[RFC 2119] Scott Bradner. Key words for use in RFCs to Indicate Requirement Levels.
RFC 2119 (Best Current Practice), March 1997. URL http://tools.ietf.org/html/
rfc2119.

[RFC 3492] A. Costello Punycode: A Bootstring encoding of Unicode for Internationalized

Domain Names in Applications (IDNA) RFC 3492 (Standards Track), March 2003 URL
http://tools.ietf.org/html/rfc3492.

[RFC 3986] Tim Berners-Lee, Roy T. Fielding, and Larry Masinter. Uniform Resource
Identifier (URI): Generic Syntax RFC 3986 (Standards Track), January 2005. URL
http://tools.ietf.org/html/rfc3986.

[Unicode] The Unicode Consortium. The Unicode Standard, Version 6.2.0. Mountain
View, CA, USA. November 2012. ISBN 978-1-936213-07-8 Section 5.18, Case Map-
pings. Paragraph about Caseless Matching. Normative URL http://www.unicode.
org/versions/Unicode6.2.0/ Informative URL ftp://ftp.unicode.org/Public/
UNIDATA/CaseFolding.txt

[UNLOCODE] United Nations Code for Trade and Transport Locations UN/LOCODE,
revision 2012-01, September 2012. URL http://www.unece.org/cefact/locode/
welcome.html.

78
GFD-R-P.206 May 2013

[WGS84] Department of Defense World Geodetic System 1984, Its Definition and Rela-
tionships With Local Geodetic Systems NIMA Technical Report TR8350.2, Third Edi-
tion, June 2004 URL http://earth-info.nga.mil/GandG/publications/tr8350.2/
tr8350_2.html.

[XML] Henry S. Thompson, David Beech, Murray Maloney and Noah Mendelsohn XML
Schema Part 1: Structures Second Edition W3C Recommendation 28 October 2004.
URL http://www.w3.org/TR/xmlschema-1/.

Informative References
[Dijkstra13] Freek Dijkstra, et al. Experimental Features for NML 1. Work in Progress.

[GFD.165] Paola Grosso, Aaron Brown, Aurélien Cedeyn, Freek Dijkstra, Jeroen van der
Ham, Anand Patil, Pascale Primet, Martin Swany, and Jason Zurawski. Network Topol-
ogy Descriptions in Hybrid Networks GFD 165 (Informational), March 2010. URL
http://www.ogf.org/documents/GFD.165.pdf.

[RFC 6350] Simon Perreault. vCard Format Specification RFC 6350 (Standards Track),
August 2011. URL http://tools.ietf.org/html/rfc6350.

[RFC 6351] S. Perreault. xCard: vCard XML Representation RFC 6351 (Standards Track),
August 2011. URL http://tools.ietf.org/html/rfc6351.

[RDFVCARD] Harry Halpin, Renato Iannella, Brian Suda, Norman Walsh Representing
vCard Objects in RDF W3C Member Submission 20 January 2010. URL http://www.
w3.org/TR/vcard-rdf/.

79