[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Moving right along ... generalized-rsvp-te-05
Maarten
Switching Type has been defined to enable for instance the
following case if i well understood the explanations given
in the existing I-Ds:
--- CF ---
| |
link 1 | | link 2
----------- ---------
- link 1 supports TDM LSP Encoding Type
- link 2 supports TDM LSP Encoding Type
however at the end of
- link 1: PSC or LSC Switching capability can be provided
- link 2: PSC or LSC Switching capability can be provided
Notice that a Lambda LSP does not have to be established before
the setup of the packet LSP. Consequently this feature provides
additional about the implementation the Connection Function (CF)
into the switch. So i can understand why you have some problem
to understand this concept since typically CF implementation are
left unspecified. Typically what do you have in such circumstances
is the following:
link1 - CF1 - link3
| |
| |
link2 -|- CF2 -|- link4
| |
| |
---------- ---------
where CF_1=PSC and CF_2=LSC
with link 1 and link 3 supporting "packet" LSP Encoding
and link 2 and link 4 supporting "lambda" LSP Encoding
In all the examples that you have listed:
- either the switching type through the LSP EncType and Signal Type
- or only the LSP Encoding Type (in case of Ethernet for instance)
so in such cases the Switching Type provides a redundant information.
Hope this helps you to understand the underlying concept.
Cheers,
- dimitri.
Maarten Vissers wrote:
>
> Markus, John, Lou, Manoj,
>
> I also still have a major issue to understand the switching type... or more
> precise I have the feeling it is too coarse and ill defined. Let me provide some
> more examples to evaluate:
>
> Frist Markus' network example... it will look like the following in reality
>
> R1 ------ OXC1 ------ OXC2 ------ R2
> OC-N OC-N OC-N
>
> OC-N trail
> |<------------------------------>|
>
> STS-Nc trail
> |<-------------------------------->|
>
> IP Link
> |<---------------------------------->|
>
> I assume that OXC1/2 are all optical cross connects which pass through the
> complete OC-N signals.
>
> In order to route IP packets between R1 and R2, you need to set up an OC-N trail
> between R1 and R2. Once this is done, you need to set up a STS-Nc trail between
> R1 and R2. Once this is done you have an IP link with a bandwidth of 9 584 640
> kbit/s established between R1 and R2. Now IP signals can flow between R1 and R2.
>
> Now make the example a bit more complex and let me add a SONET cross connect in
> the chain.
>
> R1 ------ OXC1 ------ OXC2 ------ DXC1 ------ R2
> OC-N OC-N OC-N OC-N
>
> OC-N trail OC-N trail
> |<------------------------------>| |<------>|
>
> STS-Nc trail
> |<-------------------------------------------->|
>
> IP Link
> |<---------------------------------------------->|
>
> The physical interface in each case is an OC-N. The DXC1 is a SONET cross
> connect, which terminates the OC-N Section and Line layers and forwards the
> STS-Nc signal.
>
> What would the switching types be in this case when an LSP is requested between
> R1 and R2?
>
> Now assume that the transport network contains some OTN OXCs interconnected via
> 40G wavelengths. The Routers are having STM-16 physical interfaces with VC-4-16c
> path signal carrying IP traffic. The DXC1 is a SDH cross connect with an OTN
> OTM-0.3 (i.e. 40G) interface, which is carrying ODU1 (2G5) signals with STM-16
> inside.
>
> R1 -------- OXC1 ---------- OXC2 ---------- OXC3 --------- DXC1 -------- R2
> STM-16 OTM-64.3 OTM-40.3 OTM-0.3 STM-16
>
> OCh trail
> |<-------------------------->|
>
> ODU3 trail
> |<----------------------------------------->|
>
> ODU1 trail
> |<-------------------------------------------->|
>
> STM-16 trail STM-16 trail
> |<-------------------------------------------------------->||<-------->|
>
> VC-4-16c trail
> |<---------------------------------------------------------------------->|
>
> IP Link
> |<------------------------------------------------------------------------>|
>
> What would the switching types be in this case when an LSP is requested between
> R1 and R2?
>
> But a router may also connect via a GE interface. The ethernet frames are then
> forwarded in OXC1 via a virtual concatenated VC-4-Xv to R2 (which has a STM-16
> interface supporting VC-4-Xv). As VC-4-Xv signals can only be carried in sTM-N
> signals, there is an STM-16 trail between OXC1 and DXC1. There is another STM-16
> trail between DXC1 and R2.
> The OXCs are part of an OTN network, so the STM-16 that is created in the OXC1
> is mapped into an ODU1 and this ODU1 is switched to an OTM-64.3 port. In this
> port the ODU1 signal is TDM multiplexed into an ODU3 and this ODU3 is put onto a
> wavelenght (via OTU3V and OCh). OXC2 is an OCh (all optical) switch, capable to
> forward the true wavelenght signal between the two OTM-64.3 and OTM-40.3 line
> ports. The OCh signal is terminated in the OTM-40.3 line port in OXC3 and the
> ODU3 is switched to the egress OTM-0.3 interface port. Arriving at DXC1, the
> ODu3 is terminated, the ODU1 is demultiplexed from the ODU3, the ODU1 is
> terminated and the STM-16 is extracted. Then the sTM-16 is terminated and the X
> VC-4 signals are switched to the egress STM-16 signal. At R2 the STM-16 signal
> is terminated, the X-VC-4 signals are connected to the VC-4-Xv port and
> terminated making the ethernet frames available. The ehternet frames are
> terminated and the IP packets are now accessible.
>
> R1 ------ OXC1 ---------- OXC2 ---------- OXC3 --------- DXC1 -------- R2
> 1 GE OTM-64.3 OTM-40.3 OTM-0.3 STM-16
>
> OCh trail
> |<-------------------------->|
>
> ODU3 trail
> |<----------------------------------------->|
>
> ODU1 trail
> |<-------------------------------------------->|
>
> GE trail STM-16 trail STM-16 trail
> |<----->||<---------------------------------------------->||<-------->|
>
> VC-4-Xv (X=1..7) trail
> |<------------------------------------------------------------>|
>
> Ethernet MAC link
> |<---------------------------------------------------------------------->|
>
> IP Link
> |<------------------------------------------------------------------------>|
>
> Question is again the switching types you will see when requesting a LSP between
> R1 and R2.
>
> Regards,
>
> Maarten
>
> Markus Jork wrote:
> > Let's look at the example of two IP routers connected to a cloud of
> > opaque OXCs:
> >
> > R1 ----- OXC1 ----- OXC2 ----- R2
> > LSC LSC PSC
> >
> > OXC1 and OXC2 switch the Sonet stream from an incoming interface to
> > some outgoing interface, that's why links R1-OXC1 and OXC1-OCX2
> > are advertised as LSC in the IGP. Link OXC2-R2 is PSC because R2 looks
> > at the incoming IP packets. The encoding on the links is OC192.
> >
> > Now I want to setup an LSP between R1 and R2. (This LSP is essentially
> > a "lightpath" through the optical cloud and will be advertised as FA
> > so that PSC LSPs can be tunneled through it later.)
> > What is the switching type requested in the Generalized Label Request
> > object? I would expect LSC.
> > But section 2.1 of draft-ietf-mpls-generalized-rsvp-te-06 says:
> >
> > A Generalized Label Request object is set by the ingress node,
> > transparently passed by transit nodes, and used by the egress node.
> >
> > This would suggest the switching type needs to be PSC.
> > But then the text in 2.1.1 says:
> >
> > Nodes MUST verify that the type indicated in the Switching Type
> > parameter is supported on the corresponding incoming interface. If
> > the type cannot be supported, the node MUST generate a PathErr
> > message with a "Routing problem/Switching Type" indication.
> >
> > So when the Path message requested PSC, it would be rejected by OXC1
> > and OXC2. When it requested LSC it would be rejected by R2.
> > The transit nodes can't modify the switching type in the Path message
> > because they don't have enough knowledge to pick the right one.
> > How is this supposed to work?
> >
> > thanks for any clarification,
> > Markus
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