SD1-25 Objectnaming

SUPPORTING DOCUMENT: MTNM SUPPORT FOR A NAMING CONVENTION
Multi-Technology Network Management support for a

Naming Convention
Table of Contents
1 Objective ................................................................................................................................................ 4
2 General Rule ........................................................................................................................................... 4
3 NamingAttributes_T Structure ............................................................................................................... 4
4 Equipment Naming – General Rules and Semantics.............................................................................. 8
5 Naming of Transmission and Performance Monitoring Objects .......................................................... 10
5.1 Naming of the PTP and FTP ........................................................................................................ 10
5.2 Naming of the CTP....................................................................................................................... 11
5.2.1 Rules and Semantics ............................................................................................................. 11
5.2.2 Pre-defined Name Strings: ................................................................................................... 12
5.2.2.1 Unidirectional CTP Naming ............................................................................................. 13
5.2.2.2 Off-Network CTPs ........................................................................................................... 13
5.2.2.3 ATM Components ............................................................................................................ 13
5.2.2.4 SDH/SONET CTPs .......................................................................................................... 14
5.2.2.5 PDH CTPs ........................................................................................................................ 18
5.2.2.6 WDM ................................................................................................................................ 20
5.2.2.7 Tunable Lasers ................................................................................................................. 21
5.2.2.8 Ethernet “Flow Point” CTPs ............................................................................................ 21
5.2.3 Pictorial Depiction of the CTP Hierarchy. ........................................................................... 22
5.3 Naming of the PMP ...................................................................................................................... 23
5.4 Naming of Objects for Connectionless Transmission Management ............................................ 23
5.4.1 Note on FPs and CPTPs ....................................................................................................... 23
5.4.2 Flow Domain ........................................................................................................................ 24
5.4.3 Matrix Flow Domain ............................................................................................................ 24
5.4.4 Flow Domain Fragment........................................................................................................ 24
5.4.5 Traffic Conditioning Profile ................................................................................................. 25
5.5 Naming Objects for the ASON Control Plane ............................................................................. 25
5.5.1 MLSN when used to represent an ASON Control Plane Multi-Layer Routing Area .......... 25
5.5.1.1 Top Level MLRA ............................................................................................................. 26
5.5.1.2 Routing Node ................................................................................................................... 26
5.5.1.3 Multi-Layer aspect of MLRA........................................................................................... 27
5.5.2 MLSNPPLink ....................................................................................................................... 28
5.5.3 MLSNPP .............................................................................................................................. 29
5.5.4 Call ....................................................................................................................................... 31
5.5.5 SNC when used to represent an ASON Control Plane Connection ..................................... 31
5.5.6 Providing the identifiers of the SNP and SNPP ................................................................... 32
5.5.6.1 SNPP in an MLSNPP (e.g. as an Endpoint of a Connection) .......................................... 33
5.5.6.2 SNP in an MLSNPP (e.g. as an Endpoint of a Connection) ............................................ 33
5.5.6.3 SNPP in an MLSNPP Link (e.g. as an Endpoint of a Connection) .................................. 33
5.5.6.4 SNP in an MLSNPP Link (e.g. as an Endpoint of a Connection) .................................... 34
SD1-25 Version 3.3 TeleManagement Forum 2007 1

5.5.6.5 Remote SNPP ................................................................................................................... 34
5.5.6.6 Remote SNP ..................................................................................................................... 34
Revision History ........................................................................................................................................... 35
Acknowledgements ...................................................................................................................................... 35
How to comment on the document............................................................................................................... 35
2 TeleManagement Forum 2007 SD1-25 Version 3.3

List of Tables
Table 1: Examples of Equipment Naming ................................................................................................... 10
Table 2: PTP and FTP Naming .................................................................................................................... 10
Table 3: CTP Naming................................................................................................................................... 11
Table 4: Off-Network CTP Naming ............................................................................................................. 13
Table 5: ATM Components Naming ............................................................................................................ 14
Table 6: SDH/SONET CTP Naming............................................................................................................ 18
Table 7: PDH CTP Naming.......................................................................................................................... 20
Table 8: WDM CTP Naming ....................................................................................................................... 21
Table 9: Tunable Laser Port CTP Naming ................................................................................................... 21
Table 10: Ethernet “Flow Point” CTP Naming ............................................................................................ 22
Table 11: Flow Domain Naming .................................................................................................................. 24
Table 12: Matrix Flow Domain Naming ...................................................................................................... 24
Table 13: Flow Domain Fragment Naming ................................................................................................. 24
Table 14: TC Profile Naming ....................................................................................................................... 25
Table 15: MLRA Naming ............................................................................................................................ 25
Table 16: MLRA Level Naming .................................................................................................................. 26
Table 17: MLSNPPLink Naming ................................................................................................................. 28
Table 18: MLSNPP Naming ........................................................................................................................ 29
Table 19: Call Naming ................................................................................................................................. 31
Table 20: Connection Naming ..................................................................................................................... 31
Table 21: SNPP Naming in an MLSNPP ..................................................................................................... 33
Table 22: SNP Naming in an MLSNPP ....................................................................................................... 33
Table 23: SNPP Naming in an MLSNPP Link ............................................................................................ 33
Table 24: SNP Naming in an MLSNPP Link ............................................................................................... 34
Table 25: Remote SNPP Naming ................................................................................................................. 34
Table 26: Remote SNP Naming ................................................................................................................... 34

1 Objective
The objective of this document is to facilitate consistent naming of objects in the TMF MTNM
interface. his document defines a mandatory naming convention for Equipments, CTPs and
PMPs, as well as a recommendation for PTPs and FTPs.
2 General Rule
Wherever deterministic naming (or an indirect name) is used for a second class object, an
attribute ‘nativeEMSName’ will be added. This is a string that describes what the object is called
on the EMS.
3 NamingAttributes_T Structure
The NamingAttributes_T structure is used as a naming scheme between the NMS and EMS
interface. NamingAttributes_T is used to define identifiers for managed entities that are not
instantiated as first class CORBA objects and thus do not have object identifiers. The
NamingAttributes represent "the hierarchical name structure" of an object. The structure of the
name is hierarchical and reflects the containment relationship between objects in a simple way.
The following convention is used for the field name:
If necessary, other strings may be defined by the NMS or any EMS on an as-needed basis.
The Naming Hierarchy of names is as follows:
 EMS
1. name="EMS";value="CompanyName/EMSname"
 Subnetwork (see also MLRA below)

2. name="MultiLayerSubnetwork";value="SubnetworkName"
 SubnetworkConnection (see also Connection below)

3. name="SubnetworkConnection";value="SubnetworkConnectionName"
 ManagedElement
2. name="ManagedElement";value="ManagedElementName"
 TopologicalLink
2. name="TopologicalLink";value="TopologicalLinkName"

 PTP (see below for further detail)

3. name="PTP";value="PTPName"
 FTP (see below for further detail)

3. name="FTP";value="FTPName"
 CTP (see below for further detail)

4. name="CTP";value="CTPName"
 GTP
3. name="GTP";value="GTPName"
 PMP (see below for further detail)

4. name="PMP";value="PMPName"
OR
4. name="CTP";value="CTPName"
5. name="PMP";value="PMPName"
 TPPool
3. name="TPPool";value="TPPoolName"
 TransmissionDescriptor
2. name="TransmissionDescriptor";value="TransmissionDescriptorName"

 EquipmentHolder (see below for further detail)
3. name="EquipmentHolder";value="EquipmentHolderName"
 Equipment (see below for further detail)

3. name="EquipmentHolder";value="EquipmentHolderName"
4. name="Equipment";value="EquipmentName"
 ProtectionGroup
3. name="PGP";value="ProtectionGroupName"
 EquipmentProtectionGroup
3. name="EPGP";value="EquipmentProtectionGroupName"
 TCAParameterProfile
3. name="TCAParameterProfile";value="TCAParameterProfileName"
 AlarmSeverityAssignmentProfile
2. name="ASAP";value="AlarmSeverityAssignmentProfileName"
 FlowDomain
2. name="FlowDomain";value=" FlowDomainName"
 MatrixFlowDomain
3. name="MatrixFlowDomain"; value= "MatrixFlowDomainName"
 FlowDomainFragment
5. name="FlowDomain";value=" FlowDomainName"
6. name="FlowDomainFragment"; value="FlowDomainFragmentName”

 TrafficConditioningProfile
2. name="TCProfile";value="TCProfileName"
 MLRA (represented by and MLSN)

2. name="MLRA";value="MLRAName"
 MLSNPPLink
2. name="MLSNPPLink";value="MLSNPPLinkName"
 MLSNPP
2. name="MLSNPP";value="MLSNPPName"
 Call
2. name="Call";value="CallName"
 Connection (represented by an SNC)

2. name="MLRA";value="MLRAName"
3. name="Connection";value="ConnectionName"
 SNPP in an MLSNPP (e.g. as an Endpoint of a Connection)

3. name="RAid";value="RA Identifier"
4. name="SNPPid";value="SNPP Identifier"
 SNP in an MLSNPP (e.g. as an Endpoint of a Connection)

5. name="SNPid";value="SNP Identifier"
 SNPP in an MLSNPPLink (e.g. as an Endpoint of a Connection)


 SNP in an MLSNPPLink (e.g. as an Endpoint of a Connection, or as a resourceName
referenced by an ASAP instance)
 Remote SNPP where the MLRA is not known

 Remote SNP where the MLRA is not known

 Other Objects (for Alarm purposes)

3. name="AID";value="NameOfEntity"
The strings used for the value field of the name-value pairs will be at most 1024
characters (from ISO8859) long with white space character allowed in the value but with
no leading or trailing spaces. For instance, a value could be the string "the string
splendid" but not " the string exquisite ". All name and value strings are case sensitive.
The value field is a free format string assigned by each EMS and is not standardized
across this interface except for the EMS, CTP, EquipmentHolder, and Equipment names
(see below for further detail).
All implementations of this interface have to comply to the naming scheme defined here. It is
mandatory for conforming to this interface.
4 Equipment Naming – General Rules and Semantics

1. Components will be identified by a name=value syntax.
2. Components in a hierarchy will be separated by a ‘/’, the left most being the highest level of
containment.
3. The general hierarchy identifies the equipment-holder class, and then the circuit-packs.
4. The names “rack”, “shelf”, “sub_shelf”, “slot”,”sub_slot” identify physical (not logical)
equipment holders. The use of the “rack” and “sub_shelf” name strings is optional. The
name “Equipment” is used to identify the circuit-pack.
5. The modeling of a “remote_unit” or “remote_subslot” is may be reported in case that an
EMS manages remote equipment as an extension to the local equipment being modeled.

6. Even if a slot contains only one circuit-pack, the circuit pack is separately identified ( as
“Equipment”)
The naming of the equipment holders always starts from left to right and top to bottom in that
order, starting from 1 at the Top Left. An example is shown in Figure 4 in the SD1-
10_EquipmentModel.pdf supporting document .
Many small MEs have a single shelf, which is mounted in a rack that can be shared by other
MEs. Furthermore, MEs with a small number of shelves can be spread across multiple shared
racks. When shared racks are used, the EMS does not usually know anything about the physical
rack configuration because shared racks are entirely passive. As a consequence, reporting racks
is optional.
Names for equipment holders have the following syntax:

[/remote_unit=<ru>][/rack=<r>][/shelf=<sh>[/sub_shelf=<ssh>]
[/slot=<sl>[/[remote_]sub_slot=<ssl>]]]] Where the rack is indicated only when a rack can be
reliably reported
Examples of Equipment naming are shown in Table 1. The first two tuples, “EMS”, and
“ManagedElement” are not explicitly stated in the examples, but these always prefix the
equipment tuples.
Equipment Name Value Description

Type
Bay or a Rack “EquipmentHold “/rack=<r>” Describes the Bay.
er”
Shelf in a Bay “EquipmentHold “/rack=<r>/shelf=<sh>” Describes the shelf in a
er” bay.
Shelf without “EquipmentHold “/shelf=<sh>” Describes the shelf.
Rack er”
information
Remote shelf “EquipmentHold “/remote_unit=<ru>/shelf=<sh>” Describes the remote
without Rack er” shelf
information
Equipment in “EquipmentHold “[/rack=<r>]/shelf=<sh>” If the Equipment fits the
a shelf er” entire shelf, then that
“Equipment” “1” equipment is named with
respect to the shelf
holder.
Sub-shelf in a “EquipmentHold “[/rack=<r>]/shelf=<sh>/sub_shelf=<ssh>” Describes the sub-shelf.
shelf er”
Slot in a sub- “EquipmentHold “[/rack=<r>]/shelf=<sh>/sub_shelf=<ssh>/slot= Describes the slot.
shelf er” <sl>”
Slot in a Shelf “EquipmentHold “[/rack=<r>]/shelf=<sh>/slot=<sl>” Describes the slot.
er”

Equipment Name Value Description
Type
Circuit Pack in “EquipmentHold “[/rack=<r>]/shelf=<sh>[/sub_shelf=<ssh>]/slot Describes the circuit pack
the slot er” =<sl>” in the slot. Daughter
“Equipment” “1” boards have their own
equipment holders that
are named as sub-slots
and the boards
themselves are pieces of
equipment in those
holders.
Holder for the “EquipmentHold “[/rack=<r>]/shelf=<sh>[/sub_shelf=<ssh>]
daughter er” /slot=<sl>/sub_slot=<ssl>”
boards or sub-
slots
DaughterBoar “EquipmentHold “[/rack=<r>]/shelf=<sh>[/sub_shelf=<ssh>]
d. er” /slot=<sl>/sub_slot=<ssl>”
“Equipment” “1”
Remote “EquipmentHold “[/rack=<r>]/shelf=<sh>[/sub_shelf=<ssh>]
daughterboard er” /slot=<sl>/remote_sub_slot=<ssl>”
“Equipment” “1”
Table 1: Examples of Equipment Naming
5 Naming of Transmission and Performance Monitoring Objects
5.1 Naming of the PTP and FTP

The name of the PTP and/or FTP is with respect to the managed element as shown in Table 2.
Name Value
“EMS” <EMS Name>
“ManagedElement” <ManagedElement Name>
“PTP” <PTP Name>
Name Value
“FTP” <FTP Name>
Table 2: PTP and FTP Naming
The value part of the PTP and FTP tuple will be a free format string. This can be representative
of the position of the PTP or FTP with respect to the equipment based on the implementation

(e.g., "/rack=<r>[/shelf=<sh>[/sub_shelf=<ssh>][/slot=<sl>[/sub_slot=<ssl>]]]/port=<p>" or
"/shelf=<sh>[/sub_shelf=<ssh>][/slot=<sl>[/sub_slot=<ssl>]]/port=<p>"), but no special
constraints are imposed in this tuple.
5.2 Naming of the CTP

The CTP Naming will be relative to the PTP or FTP as shown in Table 3: CTP Naming
. This section identifies the containment of the transmission layer hierarchy of the CTP. In
addition wherever a directionality is needed, the directionality is also specified of the CTP.
Name Value
“PTP” or “FTP” <PTP Name> or <FTP Name>
“CTP” <CTP Name>
Table 3: CTP Naming
The model components that have been considered for this modeling are:
 direction
 ATM: VP/VC Index; ATM Interfaces
 WDM: Frequency
 SONET/SDH
 PDH: DSn, En
 Ethernet: VLAN tags (if applicable)
 IP (future)
5.2.1 Rules and Semantics

 CTP name refers to the name for a specific CTP that may encompass several layer rates to
include the connectable layer rate and layer rate(s) of adaptations. As such, the pre-defined
string names have been shortened to encompass the layer rates of interest in the CTP named.
 The CTP naming is intended to cover all common CTP layer rates for SONET/SDH/PDH. It
is not exhaustive, and it is anticipated that new “pre-defined strings” will be added in future
releases. New CTP name strings shall follow the conventions listed below. Not all layer rates
have CTPs at that rate. If applications arise where a specific layer rate can provide a CTP,
then these will have to be defined.
 CTP name hierarchy refers to the combination of all CTP names defining the CTP position
relative to the PTP or FTP
 Order is determined by the relevant CTP containment as defined by the EMS.
 Notation order is higher to lower orders, from left to right.

 The CTP name for each layer is defined. Where-ever multiple layers are applicable to a
particular CTP, the container layer is used.
 Layers (CTP Names) are combined to form the desired CTP name hierarchy
 A client layer CTP name is added to its server layer CTP name hierarchy to form the CTP
name hierarchy
 Given server layer CTP /name1=value1 the addition of the a client layer would result in a
CTP name hierarchy as follows /name1=value1/name2=value2
 The name and value are defined strings and there are no ‘/’ , ‘=’, ‘-‘ embedded.
 The basic format constructors are.

 / separates layers (rates) which represent actual CTPs
 “=” separates name and values
 Within a given layer, the modifiers are separated by ‘-‘.
 The basic format for a layer is /name=value
 The basic format of combined layers (CTP names) to form the containment (hierarchy):
/name1=value1/name2=value2 etc.
 The basic format of components with in a layer is /name1=value/name2=value2 etc.
 No spaces
 No trailing /
 The "name" and "value" in the "name=value" pair are lower case
The general format is as follows:

/name=value ( / ((modifier value *.( -name=value)(-name=value))*
In addition, whenever unidirectional CTPs are specified, the directionality is always prepended
to the last tuple. In case of the Bidirectional CTP, the direction tuple must be omitted.
5.2.2 Pre-defined Name Strings:

See the SD1-17_LayerRates.pdf supporting document for a complete list of naming strings for
each layerRate.
Qualifier strings:
 j - AUG index
 k - TUG-3 or AU-3 index
 l - TUG-2 index
 m - TU-12 or TU-11 index
 number - for tunable lasers
 remoteaddress - off-network CTP
 direction - allowed values are {src, sink}
 s – AU3 sliding concatenation offset
 t – AU4 sliding concatenation offset

5.2.2.1 Unidirectional CTP Naming

The following naming identifies the 1.3.2 TU12 CTP in the 4th AUGRP of an STMn:
 /sts3c_au4=4/vt2_tu12-k=1-l=3-m=2
The unidirectional ctp of the same type is identified as:
 /direction=src/sts3c_au4=4/vt2_tu12-k=1-l=3-m=2
 /direction=sink/sts3c_au4=4/vt2_tu12-k=1-l=3-m=2
5.2.2.2 Off-Network CTPs

TP Type Value Comments
Off-Network “/remoteaddress=<remote remoteaddress.value where value is a string representation
CTPs address>” of the remote address. It is not a "true" CTP and may not
be representable in the standard CTP containment
hierarchy.
Note the following for this CTP:
EMS is an empty string
ManagedElement is an empty string
PTP is an empty string
Off-network CTP name must be unique across all EMS's.
Example:
/remoteaddress=4539875455
Table 4: Off-Network CTP Naming
5.2.2.3 ATM Components
TP Type Value Comments

ATM Network /atmnetworkinterface=[1..n] The ATM Network Interface TP.
Interface
Multiple E1s E1 /atmnetworkinterface=1/e1=[1-n]
supported by
IMA capable
ATM NI
Multiple E1s VC12 /atmnetworkinterface=1/vt2_tu12=[1..n]
supported by
IMA capable
ATM NI mapped
to VC12
Vpi /atmnetworkinterface=[1..n]/vpi=[1..n] The vpi CTP with the vp index under the
ATM network interface.
Vci /atmnetworkinterface=[1..n]/vpi=[1..n]/vci=[1..n] The VCI CTP.
A remote /remoteaddress=<remote Note the following for this CTP:
destination with address>/vpi=[1..n]/vci=[1..n] EMS is an empty string

VPI,VCI ManagedElement is an empty string
specified. PTP is an empty string
Example:
/remoteaddress=4539875455/vpi=12/vci=13
Table 5: ATM Components Naming
5.2.2.4 SDH/SONET CTPs
The following represent the SONET/SDH Components:

 /line192_ms64=1 (MS CTP on regenerator for OC-192/STM-64)
 Contiguous (non-sliding) concatenation
 /sts192c_vc4_64c=[1-n]
 /sts48c_vc4_16c=[1-n]
 /sts12c_vc4_4c=[1-n]
 /sts3c_au4-j=<J>
 /sts3*Xc_vc_Xc=[1-n] where X is currently defined as 1-16. For example n in an
STM-N is n = N/S. S is the smallest number in {4, 16, 64} such that S>X.
 Sliding concatenation
 /sts3*Xc_vc4_Xc=[1-n]-s=[2-S]-t=[2-3] where sliding VC4 offset s is provided if
s > 1 and sliding STS1 offset t is provided if t > 1. S is the next smallest number
in the set {4, 16, 64} such that S > X.
 High order (potentially server) CTPs
 /sts3c_au4-j=<J>
 /sts1_au3-j=<J>-k=<K>
 Lower order CTPs, appended to the server modifiers;
 /tu3_vc3, /vt6_tu2, /vt2_tu12, /vt15_tu11
 -k=[1-3]
 -l=[1-7]
 -m=[1-4]
 /tu_value-k=[1-3]-l=[1-7]-m=[1-4]
 e.g. VC12 on STM-16 /sts3c_au4-j=5/vt2_tu12-k=1-l=5-m=2
 e.g. VT1.5 on OC-12 /sts1_au3-j=2-k=2/vt15_tu11-l=1-m=2
 SDH-PDH interface layers append to the PDH PTPs
 /sts1_au3=1 (TU-3)
 /tu3_vc3 (AU-3)
 /vt6_tu2=1 (TU-2)
 /vt2_tu12=1 (TU-12 from VC-12)
 /ds1_vt15_vc11=1 (TU-12 from VC-11)
 /vt15_tu11=1 (TU-11)
 Inversely multiplexed encapsulated signal (e.g. Ethernet)
 /encapsulation=1/sts3c_au4=[1-n]

Possible Layer Rate CTP Tuple. Comments

PTP/FTP
STM[n]_OC[3n] Multiplex /line[3n]_ms[n]=1 n=[1,4,16,64]. MS CTP on

section regenerators
Regenerator /section[3n]_rs[n]=1 n=[1,4,16,64]. RS CTP on Optical

section Physical STMn / OC3n
STM0_OC1 Multiplex /line1_ms0=1 MS CTP on regenerators

section
Regenerator /section1_rs0=1 RS CTP on Optical Physical STM0 /

section OC1
STM64_OC192 sts192c_vc4_64c /sts192c_vc4_64c=1 The number is sequential with respect

to the layer rate within the PTP
sts48c_vc4_16c /sts48c_vc4_16c=[1..4]
sts45c_vc4_15c VC4-15c on an VC4-16c When no sliding concatenation is

boundary /sts45c_vc4_15c=[1-4] supported. I.e. VC4-15c starts at
normal VC4-16c boundary.
sts45c_vc4_15c /sts45c_vc4_15c=[1-4]-s=[2-16]- t is provided when sliding

t[2-3] concatenation is supported at a VC3
granularity. If only VC4 granularity is
supported (i.e. t=1) then only s is
provided as the VC4 slide index.
sts21c_vc4_7c /sts21c_vc4_7c=[1-4]-s=[2-16]- When sliding concatenation at the

t=[2-3] VC4_7c rate is supported at a VC3
granularity.
When s=1 then it is not indicated.
Similarly t is not provided when t=1.
sts21c_vc4_7c /sts21c_vc4_7c=[1-4]-s=[2-16] Same as the above but sliding is only

supported at the VC4 granularity.
sts12c_vc4_4c /sts12c_vc4_4c=[1..16]
sts3c_au4 /sts3c_au4-j=[1..64] The layer rate represents the AUG

numbering where the number of au4s
is exactly 1.
sts1_au3 /sts1_au3-j=[1..64]-k=[1..3] The layer rate represents the AUG

numbering where the number of au4s is
exactly 1 and the number of au3s is 3
per AUG. For example, the 7th STS-1

PTP/FTP
on an OC-192 PTP would be called
“/sts1_au3-j=3-k=1”, and the 11th STS-
1 would be called “/sts1_au3-j=4-k=2”
tu3_vc3 /sts3c_au4-j=[1..64]/tu3_vc3-
k=[1..3]
vt6_tu2 /sts3c_au4-j=[1..64]/vt6_tu2-
k=[1..3]-l=[1..7]
k=[1..3]-l=[1..7]-m=[1..3]
vt15_tu11 /sts1_au3-j=[1..64]-
k=[1..3]/vt15_tu11-l=[1..7]-
m=[1..4]
STM16_OC48 sts48c_vc4_16c /sts48c_vc4_16c=1
sts12c_vc4_4c /sts12c_vc4_4c=[1..4]
sts9c_vc4_3c /sts9c_vc4_3c=[1-4] When VC4_3c is supported without

sliding concatenation

exactly 1.

per AUG
k=[1..3]
k=[1..3]-l=[1..7]
k=[1..3]-l=[1..7]-m=[1..3]
vt15_tu11 /sts1_au3-j=[1..16]-
k=[1..3]/vt15_tu11-l=[1..7]-
m=[1..4]
STM4_OC12 sts12c_vc4_4c /sts12c_vc4_4c=1


PTP/FTP

exactly 1.

per AUG
k=[1..3]
k=[1..3]-l=[1..7]
k=[1..3]-l=[1..7]-m=[1..3]
vt15_tu11 /sts1_au3-j=[1..4]-
k=[1..3]/vt15_tu11-l=[1..7]-
m=[1..4]
STM1_OC3 sts3c_au4 /sts3c_au4-j=1
sts1_au3 /sts1_au3-j=1-k=[1..3]
tu3_vc3 /sts3c_au4-j=1/tu3_vc3-k=[1..3]
vt15_tu11 /sts1_au3-j=1-k=[1..3]/vt15_tu11-
l=[1..7]-m=[1..4]
STM0_OC1_EC1 sts1_au3 /sts1_au3=1 There is no need for j and k as AU3 is

not derived out of a AUG
vt15_tu11 /sts1_au3=1/ vt15_tu11-l=[1..7]-

m=[1..4]
E4 VC-4 /sts3c_au4=1 This represents the SDH (G805 TTP)

CTP contained in a E4 PTP. For PDH
adapted to sdh/sonet. This is multilayer
CTP for support of transmission
parameters at more than 1 rate.
E3 Low order VC-3 /tu3_vc3=1
DS3 High order VC-3 /sts1_au3=1

PTP/FTP
Low order VC-3 /tu3_vc3=1 PDH adaptation; multilayer CTP
E2 VC-2 /vt6_tu2=1 8 Mbps PDH adapted to VC2. PDH

adaptation; multilayer CTP
E1 VC-12 /vt2_tu12=1 2 Mbp/s PDH adapted to VC12
DS1 TU-12 from VC- /ds1_vt15_vc11=1 This CTP has two layer rates.
11
TU-11 from VC- /vt15_tu11=1 DS1 PDH interface layers append to

11 the PDH PTPs
Ethernet encapsulation /encapsulation=1
sts3c_vc4 /encapsulation=1/sts3c_au4=[1..n]
sts1_vc3 /encapsulation=1/sts1_au3=[1..n]
VC3 /encapsulation=1/tu3_vc3=[1..n]
VC12 /encapsulation=1/vt2_tu12=[1..n]
vt15_tu11 /encapsulation=1/vt15_tu11=[1..n]
sts3*Xc_vc4_Xc /sts3*Xc_vc4_Xc=1 X = 1..64. For example a

/sts21c_vc4_7c may be used to carry a
Gig. Ethernet signal at full rate. (note
that in this case the encapsulation is
apart of the same CTP so it does not
appear in the naming hierarchy).
Table 6: SDH/SONET CTP Naming
5.2.2.5 PDH CTPs

The following are the components for the PDH CTPs.
 ds[0-3]=[1-n]
 e[1-5]=[1-n]
 e.g. DS1 on DS3 card /ds1=4
Examples:

Possible PTP Layer Rate CTP Tuple. Comments
STM16_OC48 ds3 /sts1_au3-j=[1..16]-k=[1..3]/ds3=1
DS1 extracted /sts1_au3-j=[1..16]-

from DS3 k=[1..3]/ds3=1/ds1=[1..28]
DS1 extracted /sts1_au3-j-[1..16]-

from VT-1.5 k=[1..3]/vt15_tu11-l=[1..7]-
m=[1..4]/ds1=1
STM4_OC12 ds3 /sts1_au3-j=[1..4]-k=[1..3]/ds3=1
DS1 extracted /sts1_au3-j=[1..4]-

from DS3 k=[1..3]/ds3=1/ds1=[1..28]
DS1 extracted /sts1_au3-j=1-k=[1..3]/vt15_tu11-

from VT-1.5 l=[1..7]-m=[1..4]/ds1=1
STM1_OC3 ds3 /sts1_au3-j=1-k=[1..3]/ds3=1
DS1 extracted /sts1_au3-j=1-

from DS3 k=[1..3]/ds3=1/ds1=[1..28]
DS1 extracted /sts1_au3-j=1-k=[1..3]/vt15_tu11-

from VT-1.5 l=[1..7]-m=[1..4]/ds1=1
DS3 DS3 /ds3=1 45M, 45Mbit/s async/PDH signal,
DS1 /ds1=[1..28] The number represents the DS1 CTP

in a DS3. Naming for 28 DS1s on a
DS3
DS0 /ds1=[1..28]/ds0=[1..24]
DS2 DS2 /ds2=1 6Mbit/s async/PDH signal
DS1 /ds1=[1..4] Represents DS1 on a DS2. Naming

for 4 DS1s on a DS2
DS1 DS1 /ds1=1 1.5Mbit/s async/PDH signal
DS0 /ds0=[1..24]
E1 E1 /e1=1 2Mbit/s PDH signal
DS0 /ds0=[1..31]

Possible PTP Layer Rate CTP Tuple. Comments
E4 E4 /e4=1 140 Mbit/s PDH signal
E5 E5 /e5=1 565 Mbit/s PDH Signal
ISDN DS0 /ds0=[1..2]
POTS DS0 /ds0=1
Table 7: PDH CTP Naming
5.2.2.6 WDM
The following components are used to represent the WDM management.
 Och – optical channel: Frequency – derived either from the OMS or from the drop side.
 /frequency=nnn.nn is a decimal representing the frequency in Tera Hertz (THz)
 e.g., /frequency=nnn.nn
 digital signal rate
 e.g. /dsr=1
 OMS CTP in an optical amplifier
 /oms=1
 ODU CTP in a G.709 OMS port with TDM and optical multiplexing
 /frequency=nnn.nn/odu2=1/odu1=[1-4]
Examples:
Possible PTP/FTP Layer CTP Tuple. Comments
Rate
OTS oms /oms=1 Number, meant for Optical amplifiers
OMS, OS/DSR optical /frequency=nnn.nn Frequency Number , decimals in THz
channel i.e., /frequency=191.90
odu1 /frequency=nnn.nn/odu1=1
odu2 /frequency=nnn.nn/odu2=1
odu1 /frequency=nnn.nn/odu2=1 odu1 in odu2
/odu1=[1-4]
PHYSCIAL_ELECTRICAL, dsr /dsr=1 For digital signal connectivity
OS (unspecified rate)
PHYSICAL_OPTICAL, OS optical /frequency=nnn.nn Frequency number, decimals in THz,
channel for optical connectivity
i.e., /frequency=191.90

OCH_Data_Unit_2 odu2 /odu1=[1-4]
Table 8: WDM CTP Naming
5.2.2.7 Tunable Lasers

Characteristics of the tunable lasers are such that they are a few in number and each one of them
can be tuned to some variable frequency ranges, starting at some frequency and with some
specified spacing. To achieve that the following scheme is named:
Name = “CTP”
Value = “/frequency=tunable-number=<n>
where n identifies the tunable lasers number with respect to a PTP. If a PTP has only one
tunable laser, the CTP Tuple will be

PTP
OS/DSR, OS optical channel /frequency=tunable- The number represents the laser number within a group
number=[1..n] of tunable lasers. This is invariant through the life of
the CTP. The tuned frequency, expressed as a
Transmission Parameters is represented as the variant.
Table 9: Tunable Laser Port CTP Naming
To identify the ranges for which the laser may be tuned, the following may be added to the
parameter list for the OCH CTP of the PTP:
 TUNABLE_BASE_FREQUENCY // value in nnn.nn THz

 TUNABLE_FREQUENCY_SPACING // nn GHz
 NUMBER_OF_TUNABLE_FREQUENCIES /nn
The Tunable Base Frequency starts with the lowest frequency that is applicable ( in THz) and
increases by a Tunable Frequency Spacing ( in GHz) and repeats in such a way to make available
a Number of Total Tunable Frequencies.
Once the tunable frequency is tuned by setTPData() or via createAndActivateSNC() , the value
of the Frequency is set and a new Transmission Parameter is set:
 TUNED_FREQUENCY //nnn.nn frequency.
5.2.2.8 Ethernet “Flow Point” CTPs
Ethernet Flow Points are represented by CTPs. The naming rule depends on the properties of the
Matrix Flow Domain (also known as a Bridge) that connects them.

Type of MFD Value Comments
VLAN unaware /eth=1 Only one Flow Point is present
VLAN aware with /ethvid=n Can be used either for C-VID or for S-VID in
single VLAN tag MFDs that only process a single VLAN tag.
VLAN aware with one [/ethsvid=n][/ethcvid=m] Either S-VID or C-VID or both may be
or two VLAN tags present. (The square brackets “[“ and “]”
indicate optionality.)
Proprietary /eth=P<string>
Table 10: Ethernet “Flow Point” CTP Naming
5.2.3 Pictorial Depiction of the CTP Hierarchy.
EMS=<CompanyName/EMSname>
/ManagedElement=<ManagedElementName>
/PTP=<PTPName>
/CTP=<CTPName>
/CTP=<CTPName1>
Figure 1: Bi-directional CTP Model
Figure 1 represents the relation between the tuples of a CTP. The figure describes a completely
bidirectional model.

EMS=<CompanyName/EMSname>
/ManagedElement=<ManagedElementName>
/direction=sink/CTP=<CTPName3>
/direction=sink/CTP=<CTPName2>
sink
/PTP=<PTPName>
src
/direction=src/CTP=<CTPName>
/direction=src/CTP=<CTPName1>
Figure 2: Uni-directional CTP Model
Figure 2 represents a unidirectional model, where the SINK PTP contains src CTPs which in turn
may contain other src CTPs.
5.3 Naming of the PMP

The value of the PMP name is "layer rate-location-granularity" where
 layer rate are the digits as defined in LayerRate_T, e.g. 15 for

LR_STS3c_and_AU4_VC4
 location is the string defined in PMLocation_T, e.g. PML_NEAR_END_Rx
 granularity is the string defined in Granularity_T, e.g. 15min
A complete example thus looks like “15- PML_NEAR_END_Rx-15min”.
5.4 Naming of Objects for Connectionless Transmission Management
5.4.1 Note on FPs and CPTPs

Although flow points (FPs) and connectionless port termination points (CPTPs, also known as
bridge ports) are mentioned in the model (e.g., in the names of some operations), these objects
are not explicitly modeled across the interface.
Instead,
 Flow Points are represented by CTPs. See section 5.2.2.8.

 CPTPs are represented by either:
 PTPs - if the port does not support encapsulation or link aggregation or
 CTPs - if the port does provide encapsulation but not link aggregation or
 FTPs - if the port does provide encapsulation or link aggregation.
5.4.2 Flow Domain

The name of a Flow Domain is with respect to the EMS as shown in Table 11.
Name Value
“FlowDomain” <FlowDomain Name>
Table 11: Flow Domain Naming
The value part of the Flow Domain tuple will be a free format string.
5.4.3 Matrix Flow Domain

The name of a Matrix Flow Domain is with respect to the Managed Element as shown in Table
12.
Name Value
“MatrixFlowDomain” < MatrixFlowDomain Name>
Table 12: Matrix Flow Domain Naming
The value part of the Matrix Flow Domain tuple will be a free format string.
5.4.4 Flow Domain Fragment

The name of a Flow Domain Fragment is with respect to the Flow Domain as shown in Table 13.
Name Value
“FlowDomainFragment” < FlowDomainFragment Name>
Table 13: Flow Domain Fragment Naming
The value part of the Flow Domain Fragment tuple will be a free format string.

5.4.5 Traffic Conditioning Profile

The name of a Traffic Conditioning Profile is with respect to the EMS as shown in Table 14.
Name Value
“TCProfile” <TCProfile Name>
Table 14: TC Profile Naming
The value part of the TC Profile tuple will be a free format string.
5.5 Naming Objects for the ASON Control Plane
This section provides the naming rules for the following objects:
 MLSN when used in the context of the Control Plane to represent a Multi-Layer Routing
Area.
 MLSNPPLink.
 MLSNPP.
 Call.
 SNC when used in the context of the Control Plane to represent a Connection
This section also provides rules for identifying:
 SNPP as a component of an MLSNPP or MLSNPPLink.

 SNP as a component of an MLSNPP or MLSNPPLink.
 SNPP as a remote component where the MLSNPP/MLSNPPLink is not known.
 SNP as a remote component where the MLSNPP/MLSNPPLink is not known.
5.5.1 MLSN when used to represent an ASON Control Plane Multi-Layer Routing
Area
The Control Plane Routing Areas are grouped into MLRAs. An MLRA is represented by an
MLSN over the interface. The naming rule depends on the position of the MLRA in the routing
area hierarchy. All MLRAs have a two element name, i.e. the name does not reflect the routing
area hierarchy, as shown in Table 16.
Name Value
“MLRA” <MLRA Name>
Table 15: MLRA Naming

 Built from two components “EMS Name” and “MLRA Name”
 Name value for the “MLRA Name” component will be obtained from the control plane
for all routing areas other than the top level and will be the value of the full name from
the control plane perspective (see below).
 The “EMS Name” component can be readily identified by the NMS and removed leaving
the raw Control Plane name. The “EMS Name” component has been included to ensure a
guaranteed indication at the NMS of the source of the information, as shown in Table 16.
Possible MLRA MLRA Name Comments

Top level MLRA “TLRA” The top level Routing Area is not a
named entity in the ASON Control Plane
as a consequence the EMS must fabricate
a name
Intermediate MLRA <MLRA Name> See rules in text below.
Routing Node <MLRA Name> See rules in text below.
Table 16: MLRA Level Naming
5.5.1.1 Top Level MLRA

The following considerations need to be taken into account when dealing with a Top Level
MLRA:
 It is potentially possible that there may be more than one top level routing area1 where at
least in one case in the network both top level routing areas are under the control of a
single EMS (this is NOT advised) then:
 It is the responsibility of the EMS to do the appropriate partitioning based upon the
underling ASON network
 It is the responsibility of the network operator to ensure that all resources in the
separate ASON control plane spaces are named as if they are in one name space.
 This strategy is highly beneficial when considering the possibility of future merge
of two separate ASON control plane instances to form one2.
5.5.1.2 Routing Node

The following considerations need to be taken into account when dealing with naming of a
Routing Node:
 The lowest level Routing Area (Routing Node) ”MLRA Name” value:
 Should be obtained from the control plane via discovery3
1
Where the operator has two or more isolated control plane instances.
2
Merging ASON control plane instances is outside the scope of this specification. Clearly as a result of the merge it
will be necessary for all resources to be named uniquely within the new name space. Necessary name changes will
cause objects to be deleted and recreated as noted.
3
Note that as several EMSs may have visibility of a single lowest level routing area but only one EMS may have
visibility of the Managed Element itself an EMS based mapping scheme does not appear appropriate

 In simple network deployments the operator may choose to name the Routing Node to be
the same as the value of the name of the Managed Element (or have a component of the
Managed Element name present - providing greater stability)
 This is possible as a result of the restriction in this release (see Appendix A.7.4 of
SD1-45_ASONControlPlaneManagement-Primer.pdf).
 This does rely upon appropriate control plane administration
 More complex scenarios where for example the lowest level Routing Area is a
network structure (e.g. a BLSR ring) rather than a Managed Element are not
covered by this release.
5.5.1.3 Multi-Layer aspect of MLRA

For an MLRA that represent more than one layer it is assumed that the name will have been
determined by the EMS as the control plane does not deal with multi-layer routing entities. The
network operator would need to choose one of the following schemes:
 The EMS looks the name up in a directory that provides a mapping from a set of Routing
Area names/identifiers identified by the Control Plane to a single MLRA name used on the
NML-EML interface
 The directory scheme is not specified here and is beyond the scope of the interface
 Any directory used for this purpose will need to be available network wide to all EMSs4
dealing with the control plane so that the same name translation can be performed at any
point.
 The EMS uses an algorithm to determine the mapping from the Routing Area names
identified by the control plane to the MLRA name used on the NML-EML interface:
 The naming proposed is to use a delimited string with a common name component and a
layer name component
 Two separate control plane Routing Areas “London-HighOrder@VC4” and “London-
HighOrder@VC4-4c” would become a singe Multi-Layer Routing Area (MLRA)
supporting both VC4 and VC4-4c with the ”RoutingArea_name” component
“London-HighOrder”)
 Clearly the EMSs that manage these Routing Areas will need to deal with the addition of
another Routing Area “London-HighOrder@VC4-16c” to the control plane by adding
another layer to the MLRA etc
 Each EMS5 must use the same translation method
 The naming approach in the Control Plane is beyond the scope of the MTNM team
responsibility.
 The MLRA represents only a single layer and the name value is derived directly from the
Control Plane routing area
It is necessary for each EMS in the network to manage the name generation in a consistent and
singular fashion so that any access to the network yields the same results
4
This is potentially a multi-vendor environment.
5
This is potentially a multi-vendor environment

To determine the grouping that may take place to form MLRAs the following guidelines have
been constructed:
 The lowest level MLRA is a Multi-Layer Routing Node (MLRN)
 In a simple network a MLRN represents all the resources in the Managed Element that
are available to the control plane in each layer of the MLRN
 A Managed Element cannot be represented by two RNs for the same layer (see
section A.7.4 Routing Node in supporting document: SD1-
45_ASONControlPlaneManagement-Primer.pdf), i.e. all the SNPs/SNPPs for a layer
belongs to the same RN.
 The MLRN representing a Managed Element for one particular layer need not be the
same as the MLRN representing the same Managed Element for another layer
 The partition of layers between MLRNs for one particular Managed Element need not be
the same as the partition of layers for another Managed Element
 However maintaining the same layer partitioning rules across the network is probably
of significant benefit to the network operator (e.g. all High Order layers are in the
same RN).
 Each Routing Area in the network must be represented by one and only one MLRA
 There is no change in partitioning as a result of creation of MLRAs.
It is assumed that all EMSs in the network will manage this in a consistent and singular fashion
so that any access to the network yields the same results
5.5.2 MLSNPPLink
The Control Plane SNPP Link is represented by an MLSNNPPLink. All MLSNPPLinks have a
two element name, i.e. the name does not reflect the routing area or SNPP Link hierarchy, as
shown in Table 17.
Name Value
“MLSNPPLink” <MLSNPPLink Name>
Table 17: MLSNPPLink Naming
Built from two components “EMS Name” and “MLSNPPLink Name”. The “EMS Name”
component can be readily identified by the NMS and removed leaving the raw Control Plane
name. The “EMS Name” component has been included to ensure a guaranteed indication at the
NMS of the source of the information
The value of final DN, i.e. the ”MLSNPPLink Name”, will be obtained from the control plane.
 Note that the ASON SNPPLinks are named by a concatenation of SNPP names
For an MLSNPPLink that represent more than one layer it is assumed that the name will have
been determined by the EMS as the control plane does not deal with multi-layer entities.

The network operator would need to choose one of the following schemes for generation of the
name for MLSNPPLinks:
 The EMS looks the name up in a directory for a set of SNPPLink identifiers identified by the
Control Plane
 The directory scheme is not specified here and is beyond the scope of the interface
 Any directory used for this purpose will need to be available network wide to all
EMSs dealing with the control plane so that the same name translation can be
performed at any point
 The EMS uses an algorithm that works on the various single layer routing area names (e.g.
two separate control plane SNPPLinks “London-Brighton@VC4” and “London-
Brighton@VC4-4c” would become a singe MLSNPP supporting both VC4 and VC4-4c with
the “MLSNPPLink Name” component “London-Brighton”)
 Each EMS that manages the SNPPLinks must use the same translation method
 Have only single layer MLSNPPLinks and allow direct naming from the Control Plane
 The naming approach in the Control Plane is beyond the scope of the interface
 Note that in more sophisticated networks the MLSNPPLink may represent a
concatenation of SNPPLinks at the same layer.
so that any access to the network yields the same results
Note that the MLSNPPLink will convey the names/identifiers of:

 All associated SNPP, know to the reporting EMS, at each end. For a particular end this will
include:
 The name/identifier of the SNPP in the context of the routing area to which the Link is
joined
 Optionally, the identifiers of the SNPP in the context of each of the subordinate RAs,
including the RN
 An SNPP at one level may be represented by amalgamation of several SNPPs at the
next level down and hence there may be a list of SNPP names/identifiers at each
subordinate level
5.5.3 MLSNPP
The Control Plane SNPP is represented by an MLSNPP, MLSNPP naming is shown in Table 18.
Name Value
“MLSNPP” <MLSNPP Name>
Table 18: MLSNPP Naming

The “EMS Name” component can be readily identified by the NMS and removed leaving the
raw Control Plane related name. The “EMS Name” component has been included to ensure a
guaranteed indication at the NMS of the source of the information
 The final value of the DN, i.e. the “MLSNPP Name”, will be obtained from the control plane
 This value is derived from the names of the SNPPs from which it is built. The Control
Plane SNPP name is a concatenation of:
 One or more nested routing area names.6
 Each nested routing area name values would need to be adjusted using the
approach defined in the MLRA naming section above to form a coherent
MLSNPP name.
 An optional subnetwork name within the lowest routing area level. This can only
exist if the containing RA names are present
 The subnetwork name can be the name of NE or part of the NE if it is a Routing
Node
 One or more nested resource context names
 Note: Each of the resource context name assembly is required to be the same for
all instances of SNPP that are to be assembled to form the MLSNPP.
For an MLSNPP that represent more than one layer it is assumed that the name will have been
determined by the EMS as the control plane does not deal with multi-layer entities. The network
operator would need to choose one of the following schemes::
 The EMS looks the name up in a directory for a set of SNPP identifiers identified by the
Control Plane
 The directory scheme is not specified here and is beyond the scope of the MTNM team
responsibility.
 Any directory used for this purpose will need to be available network wide to all EMSs
dealing with the control plane so that the same name translation can be performed at any
point
 The EMS uses an algorithm that works on the various single layer SNPP names (e.g. two
separate control plane SNPPs “London-EthernetServer@VC4” and “London-
EthernetServer@VC4-4c” would become a singe MLSNPP supporting both VC4 and VC4-
4c with the “MLSNPP Name” component “London-EthernetServer”)
 Each EMS that manages the SNPPs must use the same translation method
 Have only single layer MLSNPPs and allow direct naming from the Control Plane
so that any access to the network yields the same results.
Note that the MLSNPP will convey the names of:

 All associated SNPP, known to the reporting EMS related to the MLSNPP. This will include:
6
The MTNM name also includes an explicit MLRA_name“ which may be different from the routing area name
derived directly from the control plane used in the MLSNPP_name value.

 The name/identifiers of the SNPP in the context of the routing area in which the SNPP is
found
 Optionally, the identifiers of the SNPP in the context of each of the subordinate RAs
including the RN
 An SNPP at one level may be represented by amalgamation of several SNPPs at the
next level down and hence there may be a list of SNPP names/identifiers at each
subordinate level
5.5.4 Call
Call naming is shown in Table 19.
Name Value
“Call” <Call Name>
Table 19: Call Naming
guaranteed indication at the NMS of the source of the information
The value of the ”Call Name” may be supplied by the NMS or obtained from the control plane.
When obtained from the control plane it will be equal to the control plane Call ID
Note: the control plane Call ID must be the same throughout the control plane. The Call ID must
be:
 Unique in the entire network
 Same regardless of where viewed
 Same for the entire duration of the actual call in the network regardless of failures and/or
rearrangements of the control plane infrastructure
5.5.5 SNC when used to represent an ASON Control Plane Connection

The Control Plane Connection is represented by an SNC. The Control Plane Connection
Segment is represented by an SNC. Connection naming is shown in Table 20.
Name Value
“MLRA” <MLRA Name>
“Connection” <Connection Name>
Table 20: Connection Naming

guaranteed indication at the NMS of the source of the information and to maintain consistency
with existing naming.
The value of the name of the connection will be obtained from the control plane
 Note: Connection Segments do not actually exist as named entities in the ASON control
plane network will only exist where they conceptually exist in the Control Plane. This is
where the routing area offers a Routing Performer at its boundary, i.e. where there is a
Network Interface that does not provide visibility of the internals of the Routing Area.
 A connection/connectionSegment can only exist in the context of a call. The “Connection
Name” must be:
 Unique in the entire network
 The same regardless of where viewed
 The same for the entire duration of the actual connection in the network regardless of
failures and/or rearrangements of the control plane infrastructure
 The Call ID is provided by the control plane and its value is available (as a result of
signaling) to all control plane entities that deal with the call (i.e. control plane entities at the
top level of the routing hierarchy) or that deal with connectionSegments that form its route
(i.e. at subordinate levels).
 The “Connection Name” could be generated by the control plane based upon a number of
approaches. The choice of method for generation of “Connection Name” is not
mandated. Considering the “Connection Name” for Connection Segments
 It is assumed that there will be one and only one connectionSegment in any
particular routing area supporting a specific superior connection (e.g. the route of a
connection will not weave in and out of the same Routing Area).
 As a consequence it is proposed that the “Connection Name” component of the name
of the connectionSegment be the same as the “Connection Name” but no special
constraints are imposed in this.
5.5.6 Providing the identifiers of the SNP and SNPP

The control plane provides a signaling mechanism to convey the identifiers of its native
components (SNP and SNPP). The control plane does not support multi-layer constructs. In
some cases it is necessary to provide the identifier of a control plane component as a further
qualification of the name of a multi-layer control plane object available over the interface (e.g.
when a specific channel is to be selected or is being used – there is no multi-layer object that
represents the channel).
To support this in the interface it has been chosen to use the naming structure and to add contents
to this structure in the same way as the levels of naming hierarchy are added. There are a number
of options for naming depending upon the available information and the depth of resolution
required in the name.

In some cases remote a SNPid and/or the SNPPid will need to be passed to the EMS (i.e. where
there is no encapsulating MLSNNPPLink or MLSNPP). These cases are also supported below.
In all cases the values of the SNPid and SNPPid are those that have been derived from the
control plane as a result of inventory retrieval of MLSNPPLinks and MLSNPPs. These values
are the ones signaled by the control plane.
5.5.6.1 SNPP in an MLSNPP (e.g. as an Endpoint of a Connection)
Name Value
“RAid” <RA Identifier>
“SNPPid” <SNPP Identifier>
Table 21: SNPP Naming in an MLSNPP
5.5.6.2 SNP in an MLSNPP (e.g. as an Endpoint of a Connection)
Name Value
“SNPid” <SNP Identifier>
Table 22: SNP Naming in an MLSNPP
5.5.6.3 SNPP in an MLSNPP Link (e.g. as an Endpoint of a Connection)
Name Value
Table 23: SNPP Naming in an MLSNPP Link

5.5.6.4 SNP in an MLSNPP Link (e.g. as an Endpoint of a Connection)
Name Value
Table 24: SNP Naming in an MLSNPP Link
5.5.6.5 Remote SNPP
Name Value
Table 25: Remote SNPP Naming
5.5.6.6 Remote SNP
Name Value
Table 26: Remote SNP Naming

Revision History
Version Date Description of Change
3.0 April 2005

3.0 June 2005 Reference updated
3.1 December 2005 Version in names of referenced supporting documents
deleted
3.2 June 2006 Rest Restructuring of document.
Addition of Connectionless objects for Ethernet:
 Ethernet CTP (also known as a “Flow Point”)
 Flow Domain
 Flow Domain Fragment
 Matrix Flow Domain
 Traffic Conditioning Profile.
3.2 December 2006 Restructuring of document.
Addition of Connectionless objects for Ethernet:
 Ethernet CTP (also known as a “Flow Point”)
 Flow Domain
 Flow Domain Fragment
 Matrix Flow Domain
 Traffic Conditioning Profile
Addition of ASON Control Plane objects:

 MLRA represented by MLSN
 MLSNPPLink
 Call
 Control Plane Connection represented by SNC
3.3 December 2007 Updates following MTNM R3.5 Member Evaluation
comments.
Fixed table 11 to remove Managed Element from Flow
Domain naming hierarchy.
Acknowledgements
Bernd Zeuner T-Systems
Gerard Vila Alcatel-Lucent
How to comment on the document

Comments and requests for information must be in written form and addressed to the contact identified below:
Keith Dorking CIENA

Phone: +1 678 867 5007
Fax: +1 678 867 5010
e-mail: [email protected]
Please be specific, since your comments will be dealt with by the team evaluating numerous inputs and trying to
produce a single text. Thus we appreciate significant specific input. We are looking for more input than “wordsmith”
items, however editing and structural help are greatly appreciated where better clarity is the result.

SD1-25 Objectnaming

Uploaded by

Copyright:

Available Formats

SD1-25 Objectnaming

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SD1-25 Objectnaming

Uploaded by

Copyright:

Available Formats

SUPPORTING DOCUMENT: MTNM SUPPORT FOR A NAMING CONVENTION

Multi-Technology Network Management support for a

SD1-25 Version 3.3 TeleManagement Forum 2007 1

2 TeleManagement Forum 2007 SD1-25 Version 3.3

SD1-25 Version 3.3 TeleManagement Forum 2007 3

 Subnetwork (see also MLRA below)

 SubnetworkConnection (see also Connection below)

4 TeleManagement Forum 2007 SD1-25 Version 3.3

 PTP (see below for further detail)

 FTP (see below for further detail)

 CTP (see below for further detail)

 PMP (see below for further detail)

SD1-25 Version 3.3 TeleManagement Forum 2007 5

 Equipment (see below for further detail)

6 TeleManagement Forum 2007 SD1-25 Version 3.3

 MLRA (represented by and MLSN)

 Connection (represented by an SNC)

 SNPP in an MLSNPP (e.g. as an Endpoint of a Connection)

 SNP in an MLSNPP (e.g. as an Endpoint of a Connection)

 SNPP in an MLSNPPLink (e.g. as an Endpoint of a Connection)

SD1-25 Version 3.3 TeleManagement Forum 2007 7

 Remote SNPP where the MLRA is not known

 Remote SNP where the MLRA is not known

 Other Objects (for Alarm purposes)

4 Equipment Naming – General Rules and Semantics

8 TeleManagement Forum 2007 SD1-25 Version 3.3

Names for equipment holders have the following syntax:

Equipment Name Value Description

SD1-25 Version 3.3 TeleManagement Forum 2007 9

Table 1: Examples of Equipment Naming

5 Naming of Transmission and Performance Monitoring Objects

5.1 Naming of the PTP and FTP

Table 2: PTP and FTP Naming

10 TeleManagement Forum 2007 SD1-25 Version 3.3

5.2 Naming of the CTP

Table 3: CTP Naming

5.2.1 Rules and Semantics

SD1-25 Version 3.3 TeleManagement Forum 2007 11

 The basic format constructors are.

The general format is as follows:

5.2.2 Pre-defined Name Strings:

12 TeleManagement Forum 2007 SD1-25 Version 3.3

5.2.2.1 Unidirectional CTP Naming

5.2.2.2 Off-Network CTPs

Table 4: Off-Network CTP Naming

5.2.2.3 ATM Components

TP Type Value Comments

SD1-25 Version 3.3 TeleManagement Forum 2007 13

Table 5: ATM Components Naming

5.2.2.4 SDH/SONET CTPs

The following represent the SONET/SDH Components:

14 TeleManagement Forum 2007 SD1-25 Version 3.3

Possible Layer Rate CTP Tuple. Comments

STM[n]_OC[3n] Multiplex /line[3n]_ms[n]=1 n=[1,4,16,64]. MS CTP on

Regenerator /section[3n]_rs[n]=1 n=[1,4,16,64]. RS CTP on Optical

STM0_OC1 Multiplex /line1_ms0=1 MS CTP on regenerators

Regenerator /section1_rs0=1 RS CTP on Optical Physical STM0 /

STM64_OC192 sts192c_vc4_64c /sts192c_vc4_64c=1 The number is sequential with respect

sts3Xc_vc4_Xc /sts3Xc_vc4_Xc=1 X = 1..64. For example a