[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Moving right along ... Switching Type
Zhi,
Consider multi-switching OTN devices having transparent
OCh_CF and switching capabilities allowing optical signal
regeneration if the Switching Type is set by the ingress
node how can i change the switching type when the signal
would need to be regenerated ? This is i think a case
were more flexibility is needed moreover when these
regeneration capabilities are limited over the network.
However, here the switching type does not help since the
regeneration decision is taken locally.
Now consider a case were the ODU_CF is on top of the OCH_CF
the edge-to-edge policy applies (the switching type won't
change from ingress to egress) in such a case the encoding
"OCh" would correspond to the switching type "lambda" same
behaviour applies for ODU switching layer. Here therefore
"identification" is enough and putting the the Switching type
in the signalling does not need to be involved while it
doesn't harm in fact - this is typically the situation
with the ASON/ASTN model.
However, there is a case were such capability is useful
it is when having multiservice devices and several policies
have to be applied at the ingress for instance use the
most suitable switching capability depending on the
connection request, parameters, capabilities, etc. in
such a way that the local decision can be performed by
the ingress when specifying the switching type.
Nevertheless if i have to follow your reasoning, the TE
decision can be performed at the ingress but after you
don't need to identify the switching type to be used
Could you then tell me how to describe the latter case ?
Where i agree is that on this specific issue, more text
would be really welcome,... one can not afford to use
different semantic and processing for the same parameter.
And does not apply to any "multiservice" case since some
of them could be implicitly inferred.
- dimitri.
Zhi-Wei Lin wrote:
>
> Hi John,
>
> I think I've mentioned this before, but I'll repeat myself. I think
> switching capability may have be useful in identifying what is allowable
> for routing purposes and for discovery purposes.
>
> But once those are identified, signaling does not need to get involved.
> You responded to Ben that the switching capability field is end-to-end
> and does not change in intermediate nodes. Is this right?
>
> Zhi
>
> John Drake wrote:
>
> > Ben,
> >
> > I think part of the problem is that you also need to read the GMPLS routing
> > drafts:
> >
> > http://search.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-routing-00.txt
> >
> > There are also comments in your text.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com]
> > Sent: Monday, October 29, 2001 9:53 AM
> > To: Kireeti Kompella
> > Cc: ccamp@ops.ietf.org
> > Subject: Re: Moving right along ... Switching Type
> >
> >
> >
> > In reviewing the GMPLS signaling drafts I have been unable to
> > get a clear understanding of the need for and use of the Switching
> > Type field in the Generalized Label Request object.
> >
> >
> > JD: The Switching Type field is for handling the situation where there
> > are multiple switching capabilities per interface (see section 6.4.6 of
> > draft-ietf-ccamp-gmpls-routing-00.txt)
> >
> >
> > This appears to be an attempt to address LSP setup involving multiple
> > layer networks, but it does not adequately address the issues involved.
> >
> >
> > JD: Would you please provide some additional prose explaining your
> > reasoning on this?
> >
> >
> > That it "Indicates the type of switching that should be performed on a
> > particular link." makes it seem to be a local concern, while others
> > have indicated it is an end-to-end field. For example, George Swallow
> > says "It is my understanding that for a given LSP it does not change,
> > but is carried end-to-end and applies at all intermediate hops along
> > the path."
> >
> >
> > JD: I think George's interpretation is correct, and I don't think the
> > other text you quoted contradicts George. If a given TE link supports
> > multiple switching types, the node controlling that link needs to know
> > what switching type a given LSP wants to use.
> >
> >
> > As an end-to-end item I have trouble understanding how the originating node
> > would determine how to set this (on what basis one determines what switching
> > choice to make in all cases). In fact, I'm not sure why the originating
> > node would care what type of switching is used as long as the LSP is
> > delivered
> > to the egress faithfully.
> >
> >
> > JD: The orgin node uses the switching capability information in the link
> > state
> > database in its CSPF calculation to ensure that switching capability is
> > consistent
> > along the path of the LSP.
> >
> >
> > Regards,
> > Ben Mack-Crane
> >
> >
begin:vcard
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NA (NSG) - Antwerpen
version:2.1
email;internet:dimitri.papadimitriou@alcatel.be
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard