|
Does it satisfy the perceived "multi-hop WAN
compatibility" requirement to pack "raw bytes" into nx10G OTN frames (or
more technically into OPUs) below the HSSG MAC layer? The "raw
bytes" would be defined as the output of a new Ethernet PCS
striping protocol which would allow reassembly of the bytes at the other
end of the "link" with appropriate deskew. This is closer to a
conventional OSI structure.
Or, is the desire really to run over existing
links with true Ethernet packets? This does seem beyond the scope of the
HSSG.
Thanks,
Myles
----- Original Message -----
Sent: Monday, August 14, 2006 9:28
PM
Subject: Re: [HSSG] MAC Data Rate of
Operation Objective
Colleagues-
While multi-hop laneing might be an
interesting concept,
it would be out of scope for 802.3
(it MIGHT be in
scope for 802.1, but I don't think so)
It would violate our traditional
layering model to such an extent that I suspect it would break a LOT of other
stuff.
Geoff
At 05:07 PM 8/14/2006 , OJHA,JUGNU
wrote:
Steve,
Many of your questions
are answered in messages just exchanged between Geoff Thompson and me.
To address some of the others:
A multi-hop solution
without realignment/reassembly sounds difficult, if not impossible:
1) How would intermediate nodes read the
destination MAC address?
2) The inter-channel skew would be
effectively unbounded.
The question of what channel rates
higher than 10G to use is related to the question of mixing and matching
lanes of differing speeds. For starters, I think we should apply some
judgment on the latter issue i.e., would anyone really want to mix 10G and
1G lanes to build a really fat pipe? If we re talking about a pipe of
20-100 G or more, do additional 1G increments really add any value?
Regarding lane speeds higher than 10G, the question becomes, Can we define
aggregation of lanes whose speeds are as yet unknown, or do we have to make
a decision today on speeds (and hence, technologies) that don t exist
yet? Do we use 25G, 33.3G, 40G, 50G? This future-gazing is a
tricky business.
Best wishes,
Jugnu
From: Trowbridge,
Stephen J (Steve) [mailto:sjtrowbridge@xxxxxxxxxx]
Sent:
Monday, August 14, 2006 3:23 PM
To:
STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: Re: [HSSG] MAC Data
Rate of Operation Objective
John,
In some respects, I think that (A)
and (B) in your description might be good candidates to tackle in separate
projects (PARs).
Let me comment on proposal (B) first:
I
would characterize this as a study of "Multiple Lane Approaches". Here,
there are a number of questions to be answered:
1) Is the number of
"lanes" fixed or variable?
2) Can the interface operate at reduced
bandwidth in the presence of failure of individual lanes?
3) What is
the network architecture governing the multi-lane interconnection? Are
multiple lanes carried over a single span only, or can the lanes be carried
independently across a network and only reaggregated at the endpoints?
(attractive feature here: not necessary to build the new interface on every
network element along a path between ultra-high rate endpoints to provide an
ultra-high rate service. Network elements transporting individual lanes can
be blissfully unaware that that lane is part of a larger aggregate). This
network architecture has an impact on the differential delay that may need
to be accommodated across the lanes when they are re-aggregated.
4)
Are the individual lanes carried over existing or new physical
interfaces?
5) Can we learn from or reuse the capabilities from ITU-T
Virtual Concatenation and LCAS to provide this kind of physical layer
aggregation?
Back to proposal (A), I think that even those of us who
think that (B) is an important problem to solve do not believe that 10G is
the highest rate we will ever have for serial transport. So the way I would
like to see (A) approached is to study what the next potential serial
interface rate above 10G should be and what its characteristics are. Here,
we could study 100G, 40G or other rates that provide a suitable evolution
and are supported by the technology.
40G has some attractive characteristics since it could
reuse components from transport interfaces at the same rate (SONET OC-768,
SDH STM-256, or OTN OTU-3). Note that in one sense, we already have WAN PHY
type interfaces at 40G if you consider Ethernet frames mapped via GFP-F into
SONET OC-768c, SDH VC4-256c, or OTN OPU3.
Of course even 40G is not the highest rate interface
that we will ever build, so even if 40G is considered to be an evolutionary
step along the path of increasing bandwidth, it is worth studying what the
next serial rate should be above
40G.
Regards,
Steve
-
- From: John DAmbrosia [mailto:jdambrosia@xxxxxxxxxxxxxxxxxxx]
- Sent: Monday, August 14, 2006 3:20 PM
- To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
- Subject: [HSSG] MAC Data Rate of Operation Objective
- All,
-
- In regards to proposed MAC data rates, I have seen two basic
proposals
-
- Proposal A) 100 Gb/s
- Proposal B) Scalable Solution
-
- Proposal A supports the traditional 10x increase in speed.
-
- Proposal B, as presently discussed, is unbounded. (The
following are only my observations of statements made on the reflector
by others) The lowest limit proposed was a 4x10 approach for 40
Gb/s. No upper limits have been proposed. It has been
suggested that this approach should use existing PMDs, but there have
been also been comments regarding use of 10G, 25G, and 40G lambdas, but
that carriers would want to leverage their existing DWDM layer, which
mean baudrate in the 9.95-12.5 Gig. Consuming wavelengths has been brought up as a possible
concern. It was also suggested that the greatest bandwidth demands
are on VSR links < 50m and that the longer reach (>10km) may be
able to live with 4x10G. (Data in support of these observations
that could be used to guide the creation of objectives would be
welcome.)
-
- An objective for Proposal A could be similar to what was done for 10
GbE Support a speed of 100.000 Gb/s at the MAC/PLS service interface.
-
- For Proposal B, given its current unbounded nature and multiple
discussion points, I am not sure what would be proposed. I am
looking to the advocates of this proposal to provide some verbiage to
the reflector for discussion. Using the objective above as a
basis: Support a speed greater than 10.000 Gb/s at the MAC/PLS service
interface, would create too broad an objective.
-
- Also for both proposals what are people s thoughts on an objective
that would specify an optional Media Independent Interface (MII)?
-
- John
-
-
-
-
-
No virus found in this incoming message.
Checked by AVG Free
Edition.
Version: 7.1.405 / Virus Database: 268.10.9/417 - Release Date:
8/11/2006
|