Subject: Re: ason-routing-reqts: issue 2 architecture

From: Jonathan Sadler <[email-masked]>
Date: Tue, 16 Mar 2004 16:08:03 -0600

Adrian -

Yes, however it isn't limited to what you have in the picture.  Take the
following picture:

Logical
Topology           +-++
           --------+T1+--------
                   +--+

Physical
Realization

          ---------------   ----   ----
         |R1             | |R2  | |R3  |
         | +-----------+ | |+--+| |+--+|
         | |L1         | | ||L2|| ||L3||
         | +-----------+ | |+--+| |+--+|
         | :     :     : | | :  | | :  |
          -+-----+-----+-   -+--  | :  |
 Control   :     :     :     :    | :  |
 ----------+-----+-----+-----+----+-+--+-------
 Data      :     :     :     :    | :  |
          -+     :     +-    :    | +- |
   ------+P1+---------+P3+--------+|P5|+----
          --     :    /--\   :    | -- |
             \  -+-  /    \  +-  / ----
              \|P2 |/      \|P4|/
                ---          --

L1, L2, and L3 are aware of the topology of P1-P5, and therefore can
progress a signalling request presented to L1 through the nodes, but are
not sharing it with the outside world.  The only topology seen is T1.
The reason for doing this could be due to policy (hiding) or
scalability.  (See draft-ietf-ipo-carrier-requirements for more
explanation on why this is good)

Note here that the Logical topology being advertized (characterized by
Tn) is different from the control plane realization (Ln) as well as the
data plane realization (Pn).  This is possible in the ASON architecure,
as there is no limitation in how a function is realized.

In this case, you wouldn't be able to have separate Router IDs for each
Pn, as the single T1 shown above must use the same Router ID for the
link endpoint names in order make only a single node appear in the
topology.  However, since the resource information for the link
ingressing at P1 as well as the link egressing at P5 are in R1 and R3,
it is problematic to have a single Router ID.

Jonathan Sadler

Adrian Farrel wrote:

> All,Does the following picture capture what we want to
> achieve?               ------------------     ------
> |R1                |   |R2    |            |  --    --    --  |   |
> --  |    ------            | |L1|  |L2|  |L3| |   | |L4| |   |R3
> |            |  --    --    --  |   |  --  |   |  --  |            |
> :     :     :  |   |   :  |   | |L5| |Control
> ---+-----+-----+--     ---+--    |  --  |Plane           :     :
> :          :      |   :
> |----------------+-----+-----+----------+------+---+--+-Data
> :     :     :          :      |   :  |Plane          --     :
> --         --      |  --  |
> ----|P1|--------|P3|-------|P4|-----+-|P5|-+-               -- \   :
> / --         --      |  --  |                   \ --
> /                     |      |
> |P2|                       ------                     -- Pn is a
> physical (bearer/data/transport plane) node.Rn is a control plane
> "router"Ln is a logical control plane entity that manages a single
> physical node. Thus:R3 represents an LSR with all components
> collocated.R2 shows how the "router" component may be disjoint from
> the switchR1 shows how a single "router" may manage multiple switches
> If you can confirm this generalisation, then we can show (or fail to
> show)A. That this is a requirementB. That this can be achieved using
> existing protocols  Cheers,Adrian. PS. Those not familiar with GSMP
> may want to take a quick peak. ----- Original Message -----From: "Don
> Fedyk" <[email-masked]>To:
> <[email-masked]>; "Ong, Lyndon" <[email-masked]>Cc:
> "Adrian Farrel" <[email-masked]>; "Brungard, Deborah A, ALABS"
> <[email-masked]>; <[email-masked]>Sent: Tuesday, March 16, 2004
> 7:34 PMSubject: RE: ason-routing-reqts: issue 2 architecture > Dimitri
>
> >
> > If you are saying the real or logical node id that is associated
> with the
> > Data (bearer) plane should be unique? I would say yes.
> >
> > If you are saying could it be IP address format? I would say yes.
> (Note the
> > link identifiers in IP address format are unique only with respect
> to the
> > node id).
> >
> > But if you say Should it then follow each piece of equipment has
> knowledge
> > of this IP address format that is assigned to it? I would say no
> because
> > there is equipment that won't have this for some time. (A
> requirement I
> > understand from ASON).
> >
> > So what I believe you are left with is some bearer equipment which
> has TE
> > resources (a node Identifier (non-IP) and link identifiers
> (non-IP)). This
> > equipment is known by its native identifiers to the entity in the
> control
> > plane which can assign: IP format identifiers to the equipment
> (through some
> > means) and an unique node identifier. This can then be advertised on
> its
> > behalf as a GMPLS compatible TE LSA.
> >
> > This does create some challenges but in reality I think many devices
> are
> > known by more than one name. (Look at VoIP, devices they have 2
> identifiers
> > E.164 and IP. I personally never use my IP address to make a VoIP
> phone call
> > but I know that it is routed to a IP address along the way that is
> hidden
> > from me.)
> >
> > I tend to agree with Lyndon that Topology is derived from TE
> advertisements.
> > I don't understand what you could do without a unique logical node
> > associated with the TE links.
> >
> > Don
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]]
> > > Sent: Tuesday, March 16, 2004 1:48 PM
> > > To: Ong, Lyndon
> > > Cc: Fedyk, Don [BL60:1A00:EXCH]; Adrian Farrel; Brungard,
> > > Deborah A, ALABS; [email-masked]
> > > Subject: Re: ason-routing-reqts: issue 2 architecture
> > >
> > >
> > > the problem is not an issue of being cleaner, the issue
> > > is once the following assumption is taken (which is the
> > > logical consequence of rfc 3630 in the gmpls context)
> > >
> > > "a stable IP address of the control plane entity that
> > > manages the resources on behalf of the data plane
> > > entity whose resources are being advertised."
> > >
> > > can we assume that wrt to this stable IP address the
> > > resource identification will be unique (throughout
> > > these multiple data plane entities) and in this case
> > > it holds (no additional level of indirection needed),
> > > or not (i.e. you will find duplicated id space values
> > > and then an additional level of indirection is needed)
> > >
> > > the problem of the design team was not define the issue
> > > but to find enough arguments wrt to the operational
> > > practices (ie user community) in order to close this
> > >
> > > thanks,
> > > - dimitri.
> > >
> > > Ong, Lyndon wrote:
> > > > I had the same assumption as Don, that the RFC treats the
> > > advertising
> > > > router and the bearer plane node as the same. It would be
> > > cleaner if
> > > > there was also a bearer plane node identifier in the
> advertisement.
> > > >
> > > > Cheers,
> > > >
> > > > Lyndon
> > > >
> > > > -----Original Message-----
> > > > From: Don Fedyk [mailto:[email-masked]]
> > > > Sent: Tuesday, March 16, 2004 9:56 AM
> > > > To: Adrian Farrel; Brungard, Deborah A, ALABS;
> [email-masked]
> > > > Subject: RE: ason-routing-reqts: issue 2 architecture
> > > >
> > > >
> > > > Hi Adrian
> > > >
> > > > See Comments Below,
> > > >
> > > >
> > > >>-----Original Message-----
> > > >>From: Adrian Farrel [mailto:[email-masked]]
> > > >>Sent: Monday, March 15, 2004 4:18 PM
> > > >>To: Brungard, Deborah A, ALABS; [email-masked]
> > > >>Subject: Re: ason-routing-reqts: issue 2 architecture
> > > >>
> > > >>
> > > >>I assume that the desire is to have one control plane entity
> > > >>mange multiple data plane entities (not to have one data
> > > >>plane entity managed by multiple control plane entities).
> > > >
> > > >
> > > > I agree.
> > > >
> > > >>I believe. in this context, it might be helpful to separate
> > > >>the signaling function (and the associated routing function
> > > >>for the delivery of the signaling messages) from the TE
> > > >>advertisement routing function. Since we are discussing the
> > > >>routing requirements (this is the routing DT) can I assume
> > > >>that the discussion is limited to the TE advertisement
> > > >>routing function, with the aim to have one control plane
> > > >>entity advertise the resources on behalf of multiple data
> > > >>plane entities.
> > > >>
> > > >>If all of the above, why could you not simply do this using
> > > >>RFC3630? The only wrinkle might be that the Router Address
> > > >>TLV is described as carrying "a stable IP address of the
> > > >>advertising router". Clearly, this needs to be interpreted as
> > > >>"a stable IP address of the control plane entity that manages
> > > >>the resources on behalf of the data plane entity whose
> > > >>resources are being advertised."
> > > >
> > > >
> > > > Interesting. I thought that you need a logical node id for
> > > the bearer
> > > > plane as well even though you are only advertising from a single
>
> > > > entity.  In other words, is it not the desire to have the TE
> > > > advertisements contain the same information regardless of
> whether
> > > > there is a one to one correspondence between the nodes in
> > > control and
> > > > the data plane or there is a one to many relationship? My
> > > > interpretation of RFC3630 is that it assumes the
> > > advertising router is
> > > > the same as the logical node in the bearer plane that owns the
> > > > resources. If a logical node id was added to the
> > > advertisement for the
> > > > node terminating the resources when the advertising router
> > > was not the
> > > > bearer node that owned the resources it would be clearer to me.
> > > >
> > > > Don
> > > >
> > > >
> > > >
> > > >>Am I missing something?
> > > >>
> > > >>Adrian
> > > >>
> > > >>----- Original Message -----
> > > >>From: "Brungard, Deborah A, ALABS" <[email-masked]>
> > > >>To: <[email-masked]>
> > > >>Sent: Monday, March 15, 2004 7:43 PM
> > > >>Subject: ason-routing-reqts: issue 2 architecture
> > > >>
> > > >>
> > > >
> > > >
> > > ftp://ftp.isi.edu/internet-drafts/draft-ietf->
> ccamp-gmpls-ason-routing-
> > > > reqts-
> > > > 02.txt
> > > >
> > > > The second DT issue is on the physical architecture which can be
>
> > > > supported by GMPLS (from the draft):
> > > >
> > > > ASON does not restrict the architecture choices used, either a
> > > > co-located architecture or a physically separated
> > > architecture may be
> > > > used. Some members of the Design Team are concerned that GMPLS's
>
> > > > concept of the LSR requires a 1-to-1 relationship between the
> > > > transport plane entity and the control plane entity (Router).
> They
> > > > invite CCAMP input on GMPLS capabilities to support multiple
> > > > architectures i.e. how routing protocols would identify the
> > > transport
> > > > node ID vs. the router or routing controller ID when
> > > scoping Link IDs
> > > > in a link advertisement. Deborah
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > > --
> > > Papadimitriou Dimitri
> > > E-mail : [email-masked]
> > > E-mail : [email-masked]
> > > Webpage: http://psg.com/~dpapadimitriou/
> > > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > > Phone  : +32 3 240-8491
> > >
> > >
> >
> >

-----------------------------------------
============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 16 Mar 2004 22:33:44 -0000

But this is just Forwarding Adjacencies, link bundles and logical nodes, isn't it?

So let's state the requirement and move on.

   A collection of links and nodes such as a subnetwork or RA must
   be able to represent itself to the wider network as a single 
   logical entity with only its external links visible to the 
   topology database.

Agreed?

Adrian