[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Moving right along ... Switching Type
Ewart, Yakov,
Let's address Ewart's example by means of a layer network model... once
this model is designed, the answers are normally just there... (see also the
powerpoint
file at:
ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/ASON/ewart_example.ppt
)
Client A and Client B equipment have an IP layer network with an IP connection
function (i.e. they are routers). Client A equipment has a physical interface
port of type FiberChannel (FC), Client B equipment has a physical interface port
of type STM-N/OC-N (e.g. STM-16/OC-48).
The Technology Conversion Device (TCD) has on one side a FC port and on the
other side a STM-N/OC-N port (e.g. STM-1). Between the two ports is an IP
connection function; i.e. the TCD operates at the IP layer network and forwards
IP packets from a FC port to a STM-N port. The mapping of IP signals in the
STM-N port is via POS (in this example) into a VC-4 signal and then the VC-4
signal is mapped into a STM-1.
Note - I assumed thata TCD is doing "FC into STM-1 conversion".
Is this what does boxes are doing?
The STM-1 signal is terminated in the next equipment (LSR A), which I have
assumed to be a SDH/SONET equipment. The VC-4 signal (carrying the IP stream) is
forwarded to an egress STM-N port (connected to LSR B)... LSR B is not shown in
the figure... Similarly, LSR B forwards the VC-4 signal to LSR C, where it is
forwarded to client B equipment.
Client B equipment terminates the STM-N signal, extracts the VC-4 signals and
terminates the VC-4 signals. This makes the IP signals (i.e. the packet flows)
available to the IP connection function.
So Client A, TCD and CLient B operate at the IP layer network. The IP fabrics in
these equipment are (to be) connected via IP links:
Client A TCD client B
| | | |
==== IP_link ==== ==== IP_link ====
^
supported by VC-4 trail
The IP LINK between TCD and client B equipment is (to be) supported by a VC-4
trail.
The VC-4 trail is (to be) supported by VC-4 subnetwork connections (within the
Fabrics) and VC-4 link connections (within VC-4 LINKs).
All the above described the intended connectivity... but how can this be created
in a switched network...?
3 cases are now to be considered:
---------------------------------
1) If the TCD doesn't belong to the provider's network, it is part of the USER
domain. In such case, the USER must request a VC-4 connection through the
provider's network (LSR A to LSR C), while the network just sees a VC-4 LINK at
its UNI.
The VC-4 connection request will result in the creation of the VC-4 trail
between TCD and client B, and thus the set up of the IP LINK between these two
equipment.
2) If the TCD is part of the provider's network, there is a fiber between the
USER's client A and the PROVIDER's TCD equipment, which carries the FC signal.
Both ends of the fiber terminate the FC signal, and make the IP signals
available to the higher layers in the equipment. As such, the TCD terminates an
IP LINK and deals with client A as an IP USER...
The far end has a VC-4 LINK towards client B, and deals with client B as a VC4
USER...
This mismatch can only be resolved by means of provisioning... i.e. via network
management an IP LINK is created between TCD and Client B, by setting up a VC-4
connection between TCD and the VC-4 link between LSR C and client B.
3) If the TCD is part of the provider's network and the conversion is a fully
transparent function... i.e. "in = out", then the USER equipment will get a kind
of
"VIRTUAL PORT". In such case, the TCD effectively is a box which replaces server
layer X by server layer Y. As this is hard coded, client A equipment should
learn over its signalling interface with the network that it has a VIRTUAL
VC-4/POS PORT, rather than the physical FC port. If client A now needs to create
a connection with client B equipment, it will request a VC-4 connection between
its "virtual VC-4 port" and the "VC-4 link to client B".
Assuming that we have to deal with either case 1 or 3, the connection request in
both cases will be for a VC-4 connection.
Regards,
Maarten
PS. the idea of a "virtual port" is new (at least for me); I need more examples
to see if this is a generic solution... for now it allows me to solve this issue
and I am having the feeling that I can use this solution in other cases I have
come along in the past.
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