[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Moving right along ... generalized-rsvp-te-05
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:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:mvissers@lucent.com
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard