RE: GMPLS issues (was - GMPLS Last Calls)

["Mannie, Eric" <[e-mail]>]

Hello Ananth,

>bala>> > 1) Type of legacy equipment needing NSAP addresses 
>bala>> > (also, is
>bala>> > this optical network element or client equipment?)
>bala>> > 2) Rough estimate of number of UNI ports needing NSAP address 
>bala>> > (2002, 2005, and 2010)
>bala>> > 3) Description of application in which this legacy equipment 
>bala>> > will use UNI
>bala>> > signaling
>bala>I don't recall seeing any response. furthermore, the NSAP
>bala>requirement was not unanimously endorsed by all carriers (at
>bala>the OIF). 
>
>From our OIF representatives, although it was not unanimously endorsed, 
>there was a significant demand for NSAP support. Well, NSAP is the main 
>non-IP type of addressing that is required. The general requirement is 
>to be able to support non-IP addresses (probably have an address 
>translation from non-IP addresses to routable addresses).
>NSAP support will be needed always (e.g. support for legacy DCC that 
>uses NSAP).  So the timeframe requirement is now. 

Could you clarify the relationship between GMPLS and NSAP addresses ?

You can run several protocol stacks in parallel over the same control
channel. For instance, if your control channel is Ethernet, you can have an
IP stack and any other kind of stack using any other kind of addresses. The
two runs in parallel. 

The different stacks run in parallel in a "ship in the night" mode. The fact
that you have for instance a TMN stack using NSAP addresses is completely
orthogonal with a GMPLS stack.

Speaking about my DCN: we have one DCN for both our transmission network and
our IP network. The ADM's are managed using TMN only, DWDM equipment's are
managed using SNMP and TMN, IP routers are managed using SNMP only.
Everything uses the same DCN.

For the TMN only equipment's we route CLNS using IS-IS and we don't use IP
at all, it is pure OSI. For simplicity, we put MAC addresses (of the ADM
Ethernet interfaces) into the NSAP addresses. You could put an IP address
inside the NSAP address if you have a dual stack running on the box, that
will even be simpler.

For the DWDM equipment's we use SNMP and TMN. Each box has an IP address and
I have to check what we do for the TMN stack. I think that it is transported
over IP, maybe using RFC1006. If I remember correctly we only configure an
IP address on the DWDM box. In that case, I presume that TSAP's are build
using this IP address.

For the IP routers that we want to manage we use SNMP (full IP stack), and
it doesn't care about TMN and NSAP addresses. We use IS-IS and OSPF for the
routing in the DCN.

The small Cisco routers in the DCN forward and route both CLNS and IP.
Indeed we use IS-IS in the dual mode for CLNS and IP. These DCN routers and
their operations are independent of the nodes that we want to manage/control
- of course.

It works fine! Anyway, in a real DCN you will have new and old equipment's
and you will need to support both. This is completely independent of the
GMPLS stack. I could do VoIP using SIP (IP telephony signaling) over the
DCN, do I have to use NSAP addresses in my VoIP stack because there is some
TMN application that runs there as well ? No, of course.

For instance, you run OSPF-TE between two new core ION backbone switches
over an IP tunnel out-of-band using the DCN. GMPLS OSPF-TE packets and GMPLS
RSVP-TE messages are encapsulated over IP and these IP packets are
transported over the IP DCN using any kind of tunnelling scheme (IP in IP,
GRE, etc). The "external" IP packets are routed using IS-IS in the DCN. The
GMPLS OSPF-TE ignores the DCN IS-IS and vice-versa. 

So the GMPLS control plane runs completely independently of all the other
stacks that are already running.

Where is the issue ? Why do we need NSAP addresses in GMPLS ?

Kind regards,

Eric