>On Jul 3, 3:55am, "Howard C. Berkowitz" wrote:
>}
>} Photonic switching, where traffic is rerouted based at the high-speed
>} stream level rather than the packet or cell level, isn't here in
>} production, but it is coming rapidly. Photonic switching will
>} complement, not replace, routing. Please do not get me started on
>} the buzzword of "optical routing." With the capacity of newer
>
> Okay, how about lambda swtiching? :-)
>
Photonic switching and lambda switching are _usually_ the same thing,
although the purists insist that in photonic (usually), the
information stays optical -- it's never converted to electrical
signals inside the relay (note that I'm avoiding the loaded term
router or switch).
As far as I can tell in all proposals I've seen, these technologies
are derivatives of MPLS, with additional information needed, say, to
equate a wavelength to a MPLS label, or to use GSMP or LDP to control
an optical cross-connect.
The Great Lie of even "conventional" MPLS is that it somehow is
independent of "routing." To be more specific, MPLS offers some
alternatives in the "packet forwarding" part of "routing," but still
depends on "path determination." I prefer to think of it as an
"overdrive" to routing that only can work after routing protocols or
static routing have defined the highway system.
In the real world, if that is meaningful in so virtual a space, the
actual sequence of events is along the lines:
1. L3 path determination, either dynamic or static, works out the
connectivity.
2. Additional mechanisms, which may be no more than additional
constraints on path determination, select Label Switched Paths (LSP).
LSPs are associated with Forwarding Equivalence Classes (FEC), which
are ways to leave your cloud (i.e., interface, output QoS, etc.)
Think of these as hop-by-hop specifications of MPLS tunnels through
an IP or other cloud that can map labels onto a cloud-specific
forwarding lookup mechanism (label between L2/L3 headers, lambda, etc.)
3. Use a label distribution mechanism (LDP, RSVP-TE, CR-LDP) to distribute
information to Label Switched Routers (LSR) on how to handle the
next hop forwarding for a specific incoming label. Remember that
the scope of a label is a single link. There is a relationship between
a label and a FEC, but it's not a one to one relationship. Loosely,
a FEC is operationally defined by sets of labels. LSRs are stupid;
they don't know much about the traffic they carry. Think of ATM
switches or LAN switches in a core with true routers at the edges.
4. Use Label Edge Routers (LER) at the ingress and egress to the cloud,
to use rules to recognize the FEC to which traffic belongs, and tag
the traffic with a label. In practical terms, the LER may have a
rule that identifies traffic and puts it on a particular path (i.e.,
LSP with ingress label).
LSRs forward the traffic given them by ingress LERs or other LSRs.
Optical routing generally has the same logic, but the optical people
tend to reinvent the wheel and the protocols. In my mind, a lambda
can be a label, a VPI/VCI can be a label, and a L2/L3 shim can be a
label. Sometimes the "difference" between optical and conventional
routing comes from marketingdroids of the routing world, while other
differences come from developers who began working with SONET, ATM,
and other telco-oriented techniques and really don't understand
Internet routing.
Yes, there are different constraints to consider in an optical cloud
than in a LAN cloud. But they are still constraints, and generic
constraint-based routing algorithms can cope with them.
Most Cisco (and indeed industry) discussions of MPLS focus, somewhat
vaguely, on #4 of the steps below. But not to consider the role of
routing mechanisms in LSP setup is to wave one's hands and say "here
a miracle happens."
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
