[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ason-routing-reqts: issue 2 architecture
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 switch
R1 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 requirement
B. 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 -----
Sent: Tuesday, March 16, 2004 7:34
PM
Subject: 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: Dimitri.Papadimitriou@alcatel.be
> > [mailto:Dimitri.Papadimitriou@alcatel.be]
> > Sent:
Tuesday, March 16, 2004 1:48 PM
> > To: Ong, Lyndon
> > Cc:
Fedyk, Don [BL60:1A00:EXCH]; Adrian Farrel; Brungard,
> > Deborah A,
ALABS; ccamp@ops.ietf.org
> >
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:dwfedyk@nortelnetworks.com]
> > > Sent: Tuesday, March 16,
2004 9:56 AM
> > > To: Adrian Farrel; Brungard, Deborah A, ALABS;
ccamp@ops.ietf.org
> > >
Subject: RE: ason-routing-reqts: issue 2 architecture
> > >
>
> >
> > > Hi Adrian
> > >
> > > See
Comments Below,
> > >
> > >
> >
>>-----Original Message-----
> > >>From: Adrian Farrel
[mailto:adrian@olddog.co.uk]
> > >>Sent: Monday, March 15, 2004
4:18 PM
> > >>To: Brungard, Deborah A, ALABS; ccamp@ops.ietf.org
> >
>>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" <dbrungard@att.com>
> >
>>To: <ccamp@ops.ietf.org>
> >
>>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 : dimitri.papadimitriou@alcatel.be
> > E-mail : dpapadimitriou@psg.com
> > Webpage: http://psg.com/~dpapadimitriou/
> > Address: Fr. Wellesplein 1, B-2018 Antwerpen,
Belgium
> > Phone : +32 3 240-8491
> >
> >
>
>