RE: GMPLS issues (was - GMPLS Last Calls)

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

Hello Ananth,

>The requirement is to support non-IP  addresses at the edge (this may
include NSAP) and 
>translate/encapsulate to a routable IP address in the core (a la in a 
>VPN scenario, where non-unique, non-IP addresses may be supported). 
>i.e, support just IP-based routing in the optical control plane.

One can support whatever you like at the edge/host. A layer above any GMPLS
controlled layer may use its own addressing, routing and signaling
independently.

For instance, if you want to use ATM with PNNI and NSAP addresses above a
photonic layer controlled by GMPLS that's fine. That should not have any
impact on GMPLS (layer independencies). An end-system will have two
addresses, one at the ATM layer and one at the IP layer for the GMPLS driver
of the photonic layer. In the same way an IP router has IP addresses at the
IP layer and ATM addresses associated with ATM drivers.

The address translation (from a "logical X address" to "physical IP
address") issue can be solved in many ways (DNS, static, via an address
resolution protocol (many were already designed), via routing integration,
etc). I don't believe that this should be embedded in the signaling protocol
used to open and maintain circuits. Too many non-related features in the
same protocol makes it more complex. So again, no impact on GMPLS.

Kind regards,

Eric

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]
Sent: Wednesday, June 13, 2001 9:07 PM
To: [e-mail]; Mannie, Eric
Cc: [e-mail]; [e-mail];
[e-mail]; [e-mail]; [e-mail];
[e-mail]
Subject: RE: GMPLS issues (was - GMPLS Last Calls)


Eric and others,
I think the NSAP support issue is being misunderstood. The requirement 
is to support non-IP  addresses at the edge (this may include NSAP) and 
translate/encapsulate to a routable IP address in the core (a la in a 
VPN scenario, where non-unique, non-IP addresses may be supported). 
i.e, support just IP-based routing in the optical control plane.
hope this helps clarify.

Ananth

-----Original Message-----
From: Eric.Mannie [mailto:[e-mail]]
Sent: Wednesday, June 13, 2001 5:32 AM
To: Nagarajan, Ananth; BRaja
Cc: Alanqar, Wesam; ccamp; Ferris, Tammy; Jones, Mark L.; mpls; Neir,
Lynn
Subject: RE: GMPLS issues (was - GMPLS Last Calls)


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