Question(s):

14

Meeting, date:

Chicago, 2003-06-09

Study Group:

15

Working Party:3

 

Intended type of document (R-C-D-TD):WD

23

Source:

Nortel Networks (Canada)

Tellabs (Finland)

Title:

Address Space Relationships in ASON

Contact:

Stephen Shew

Nortel Networks

Canada

Tel:+1-613-763-2462

Fax:

Email:sdshew@nortelnetworks.com

Contact:

Jonathan Sadler

Tellabs

Finland

Tel: +1-630-798-6182

Fax:

Email: jonathan.sadler@tellabs.com

 

Abstract

The introduction of a control plane to transport networks has created additional address spaces which are described in several recommendations [1-4].  This contribution provides a consolidated view of the address space relationships in order to assist in the development of ASON protocol requirements.

1           Introduction

The ASON architecture introduces the control plane as being separate from the transport plane.  This has important implications on the address space used for various identifiers.

There are four broad categories of addresses:

  1. Transport plane addresses.  These describe G.805 resources and multiple name spaces can exist to do this.  Each space has an application that needs a particular organization or view of those resources, hence the different address spaces.  Two subcategories are identified for this plane:

a.       OAM address spaces.  These are existing address spaces used in TL-1 [9], EMS, NMS, and OSS applications.  Generally they describe a physical locality which supports maintenance and fault correlation activities.  One can think of these addresses as giving a physical context to a (G.805) CP (timeslot).  They are separate from the addresses used to identify management applications.

b.      Transport address for control components.

                                                               i.SNPP addresses.  These addresses give a routing context to SNPs and were introduced in [1].  They are used by the control plane to identify transport plane resources.  However, they are not control plane addresses but are a (G.805) recursive subnetwork context for SNPs.  The G.8080 architecture [1] allows multiple SNPP names spaces to exist for the same resources.

                                                             ii.UNI Transport Resource Addresses.  These addresses are use to identify transport resources at a UNI reference point if they exist (SNPP links do not have to be present at reference points).  From the point of view of Call and Connection Controllers in Access Group Containers, these are names.  Control plane components and management plane applications use these addresses.

  1. Control plane addresses for components.  As per G.8080, the control plane consists of a number of components such as connection management and routing.  Components may be instantiated differently from each other for a given ASON network.  For example, one can have centralized routing with distributed signalling.  Separate addresses are thus needed for:

a.       Routing Controllers (RCs)

b.      Network Call Controllers (NCCs)

c.       Connection Controllers (CCs)

Additionally, components have Protocol Controllers (PCs) that are used for protocol specific communication.  These also have addresses that are separate from the (abstract) components like RCs.

  1. DCN addresses.  To enable control plane components to communicate with each other, the DCN is used.  DCN addresses are thus needed by the Protocol Controllers that instantiate control plane communication functions (generating and processing messages in protocol specific formats).
  2. Management Plane Addresses.  These addresses are used to identify management entities that are located in EMS, NMS, and OSS systems.

This contribution attempts to describe the relationship various ASON control components have to various address spaces and proposes guidelines on addressing semantics to make the interaction between routing controllers and connection controllers (signalling) more effective.

2.          Transport Plane Address Spaces

2.1        SNPP Names

SNPP addresses are used by control plane components to refer to transport plane resources.  They are scoped to coincide with G.805 subnetwork organization and provide scope to SNPs.  Constituents of the SNPP name are [1]:

There are three separate Transport names spaces in the ASON naming syntax

1. A Routing Area name space.

2. A subnetwork name space.

3. A link context name space.

The first two spaces follow the transport subnetwork structure and need not be related.  Taken together, they define the topological point where an SNPP is located.  The link context name space specifies within the SNPP where the SNP is.  It can be used to reflect sub-SNPP structure, and different types of link names.

An SNPP name is a concatenation of:

·         one or more nested routing area names

·         an optional subnetwork name within the lowest routing area level.  This can only exist if the containing RA names are present.

·         one or more nested resource context names.

Using this design, the SNPP name can recurse with routing areas down to the lowest subnetwork and link sub-partitions (SNPP sub-pools).  This scheme allows SNPs to be identified at any routing level.

SNP name: An SNP is given an address used for link connection assignment and, in some cases, routing. The SNP name is derived from the SNPP name concatenated with a locally significant SNP index.

Examples of SNPP name constituents are:

2.2 UNI Transport Resource Address

From [1], an address is defined for use by call controllers to identify SNPP links associated with a UNI.  It is a name from a users point of view.  These addresses are also used by management functions as a handle on service instances.  More than one of these may be assigned to the same set of resources.  These addresses are separated from SNPP names because users in Access Group Containers should not be given internal network addresses.  UNI Transport Address binding to SNPP names within the network can also be changed without changing many aspects of the service.

An example of this is the Transport Network Assigned address in OIF UNI 1.0 [10].

In order for Connection Management to setup a connection to a destination UNI Transport Address, an address resolution function is needed to map it to an SNPP address of the SNPP link that is referred to.

3.          Control Plane Addresses

For the ASON routing function, there are:

For Network Call Controllers and Connection Controllers, there are:

“Addressing of transport resources in the protocol is done by SNPP identifiers.  A pair of these would identify an SNPP link.  SNPP names are defined from transport name spaces (see Section 10, G.8080) and it is important to note that control plane names/addresses are not used for these.  For example, neither routing controller nor connection manager identifiers are used for bearer link names.”

3.1        Component Visibility of SNPPs

Control plane components can be instantiated in a variety of entity relationships.  For example in a transport network, there may be a single RC and distributed Connection Controllers.  There may also be instantiations where an RC and CC are in a 1:1 relationship.  This is similar to the architecture of GMPLS routing and signalling [12-14].

When signalling (NCCs and CCs) is distributed, the scope of an RC’s view of the transport network is usually larger.  That is, the SNPP scope for RCs is larger.  The implication of this is that when RCs compute a network connection (route) and pass it to a CC, the CC has visibility of all the hops including those outside the scope of the subnetwork that the CC function spans.

It is suggested as a guideline that in the above situation, the CC should not be required to understand the SNPPs outside of its scope.  For example, an SNP on an NE two link connections (hops) away.  A CC does need to understand the remote SNPP name of links exiting the subnetwork it spans.  This is effectively obtained by LRM-LRM interaction [1].

One implication of this guideline is that if information about a connection is obtained in crankback or feedback (i.e., what failed), then the CC should not have to understand the semantics of that information.  It is only opaque information that is useable by the RC.

Another implication is that when creating explicit routes [4-6], use of the local SNPP name is preferred in specifying the next SNPP link (next hop).  In GMPLS terminology [5,6], this is an “upstream” hop.

3.2 Name Space Interaction

In order for the path computation function of an RC to provide a path to a connection controller (CC) that is meaningful, they must use the same SNPP name space.  Figure 1 illustrates that the RC and CC share a common SNPP name space.  For interactions between these functions, common encodings of the name spaces are needed.  For example, the path computation function should return a path that CCs can understand.  Because SNPP name constituents can vary, any RC and CC co-ordination requires common constituents to be used.  For example link contexts should be the same.  If an RC returns say a card context for links, then the CC needs to be able to understand it.  Similarly, crankback/feedback information given to RCs from a CC should be encoded in a form that the RC PC can understand.

The SNPP name that an NCC resolves a UNI Transport Address to must be in the same SNPP name space that both RC and CC understand.  This resolution function resides in the control plane and other control plane identifiers may be associated with this function.

For convenience of operations, it may be useful to have common names between name spaces.  An example would be for the NE part of a lowest level SNPP name (the subnetwork name) to use the same value and format as that which is used in the TID in the TL-1 “name space” for that NE.  This example is fairly useful because the NE is a common sized or scoped entity in both name spaces.

3.3 Multiple SNPP Name Spaces

G.8080 does not restrict how many SNPs can be used for a CP.  This means that there can be multiple SNPP name spaces for the same subnetwork.  An important design consideration in routing hierarchy can be posed as a question of whether one or multiple SNPP name spaces are used.  In Figure 2, RA-1 contains RA-2 and RA-3.  If separate SNPP name spaces are used in each RA, then a mapping needs to be maintained between RA-1 names and corresponding SNPP names in RA-2 and RA-3.

Alternately, a common SNPP name space could be used for all three RAs.  This would likely have a hierarchical structure.  An example was given in [15]:

If a fixed length SNPP name is desired, it is possible to still have limited recursion as the following example design shows.  The technique from the Classless InterDomain Routing (CIDR) scheme of IPv4 is borrowed to do this.  Suppose that an SNPP name A is of length 32 bits.  Of these bits, only the highest 9 are significant and have the value x.  A lower level SNPP name, say A1, with the same “root” as SNPP name A, can be constructed with 32 bits where the highest 16 are significant and the top 9 bits have the value of x.  There can be 2**7 such SNPP names.  The scheme can of course continue until all 32 bits are significant.  This is an only an example of how a fixed length name could be constructed that fits the requirements.

An advantage of maintaining separate SNPP name spaces for routing hierarchy is that it enables level insertion/removal without the difficulty of adjusting name lengths.  A disadvantage is that the mapping has to be maintained.

Multiple SNPP name spaces also have an impact on address resolution between UNI Transport Resource Addresses (e.g., OIF TNAs) and SNPP names used by routing.

3.4 OSPF Routing Example

The following table illustrates the linkage between ASON component addresses and OSPF identifiers.

Architectural Name

Instance in OSPF-TE

Address Space

DCN Address.  This is the address used by the RC PCs to communicate with each other.  It is also known as the RC PC IP address.

Source and Destination Addresses in the IP packet header of the packet containing OSPF PDUs.

Should be from the DCN Address space and be a separate from the DCN address for signalling.  Both may have the same value but there should not be any dependency on this situation.

DCN Address.

Router Address TLV in [14].  This is contained in the Traffic Engineering LSA of the Opaque type 10 LSA

Also used in [14] in a separate RouterAddress TLV.  Its useage is unclear.

[14] states that this address is “reachable”

RC ID

Router ID.  Sent in OSPF PDUs.  Used to identify the source of a PDU.

Should be separate from RC PC IP address.  Should not be from the address space used for IP interfaces (a common OSPF configuration mistake)

RC ID

Advertising Router ID.  Contained in LSAs.  Usually is different from Router ID.

Same space as the Router ID.

RC ID

The Hello packet has 3 more RC IDs:

Designated Router, Backup Designated Router, Neighbor

Same space as the Router ID.

Matrix ID (subnetwork ID)

From [16]:

Local Node ID, Remote Node ID,

Node ID sub-TLVs

Used for inter or intra domain TE link to indicate the link endpoints

Should be separate from RC ID and RC PC IP addresses.

SNPP name – NE context

From [14,16]:

Link ID in Link TLV of the TE LSA.

Link Local Identifier and Link Remote Identifier sub-TLVs of the Link TLV in the TE Link Local LSA.

In [13,14] This is from the same space as RC ID.  For ASON these must be separate.

 

3.5 IS-IS Routing Example

The following table illustrates the linkage between ASON component addresses and IS-IS identifiers.

Architectural Name

Instance in IS-IS-TE

Address Space

DCN Address.  This is the address used by the RC PCs to communicate with each other.  It is also known as the RC PC IP address.

Source and Destination Addresses in the IP header of the GRE packet containing IS-IS PDUs.

Should be from the DCN Address space and be a separate from the DCN address for signalling.  Both may have the same value but there should not be any dependency on this situation.

DCN Address.

Traffic Engineering Router ID TLV [18]

[18] states that this address is “reachable”

RC ID

System ID.

This is separate from the RC PC IP address. 

RC ID

LSP ID in the LSP header (contains the advertising System ID)

Same space as the System ID.

RC ID

L1DIS, L2DIS, list of neighbours

Same space as the System ID.

Matrix ID (subnetwork ID)

From [17]:

Local Node ID, Remote Node ID,

Node ID sub-TLVs

Used for inter or intra domain TE link to indicate the link endpoints

In [18,19] This is from the same space as RC ID.  For ASON these must be separate.

Should be separate from RC ID and RC PC IP addresses.

SNPP name – NE context

From [17]:

Node ID

Should be from the same space as the Matrix ID.

 

4. Conclusion

The introduction of a control plane to transport networks has created additional name spaces.  Interactions between these name spaces and with other transport name spaces must be considered for OAM functions and protocol controller design.  Some guidelines are suggested for scoping a connection controller’s understanding of the SNPP name space, for how name spaces could interact, and use of a common SNPP name space by RC and CC components.  An issue in routing hierarchy naming was also described as an issue of common or single SNPP name spaces.

Finally, various mappings may need to be maintained between the new transport name spaces, and possibly to control addresses as well.

References

  [1]    ITU-T Recommendation G.8080/Y.1304 (2003), “Architecture for the Automatically Switched Optical Network (ASON)”

  [2]    ITU-T Recommendation G.7715/Y.1706 (2003), “Architecture and Requirements for Routing in the Automatically Switched Optical Network”

  [3]    ITU-T Recommendation G.7713/Y.1704 (2001), “Distributed Connection Management”

  [4]    ITU-T Recommendation G.7713.1/Y.1704.1 (2003), “Distributed Call and Connection Management (DCM) based on PNNI”

  [5]    ITU-T Recommendation G.7713.2/Y.1704.2 (2003), “DCM Signalling Mechanism Using GMPLS RSVP-TE”

  [6]    ITU-T Recommendation G.7713.3/Y.1704.3 (2003), “Distributed Call and Connection Management (DCM) using GMPLS CR-LDP”

  [7]    ITU-T Recommendation G.805 (2000), “Generic Functional Architecture of Transport Networks”

  [8]    ITU-T Recommendation G.831 (2000), “Management capabilities of transport networks based on the synchronous digital hierarchy (SDH)”

  [9]    Telcordia GR-831-CORE, “Operations Application Messages – Language for Operations Application Messages”, 1996

[10]    OIF UNI-01.0, “User Network Interface (UNI) 1.0 Signaling Specification”

[11]    IETF RFC 2328, “OSPF version 2”, April 1998

[12]    IETF <draft-ietf-ccamp-gmpls-routing-05.txt>,”Routing Extensions in Support of Generalized MPLS”, February 2003

[13]    IETF <draft-ietf-ccamp-ospf-gmpls-extensions-09.txt>, “OSPF Extensions in Support of Generalized MPLS”, December 2002

[14]    IETF <draft-katz-yeung-ospf-traffic-09.txt>, October 2002

[15]    Contribution D596, “SNPP Naming requirements and design”, Q12 WP3/15, January 2003.

[16]    WD19, “OSPF Extensions for ASON Routing”, Q14 WP3/15, June 2003

[17]    WD28, “ENNI Routing Protocol based on IS-IS”, Q14 WP3/15, June 2003

[18]    IETF <draft-ietf-isis-traffic-04.txt>, “IS-IS extensions for Traffic Engineering”, December 2002

[19]    IETF <draft-ietf-isis-gmpls-extensions-16.txt>, “IS-IS Extensions in Support of Generalized MPLS”, December 2002