[Nsi-wg] call tomorrow - 6/24
Jerry Sobieski
jerry at nordu.net
Tue Jun 23 20:59:48 CDT 2009
Hi all-
I will not be able to make the call as I will be in the air. But a
couple comments...
First- Radak's diagram on chain and tree models is very good...Might we
indicate where the User Agent initiates a request? We understand from
our discussions that the service provider can play that role in the
diagram, but it may not be as obvious to the casual reader...
Second...Regarding asymetric framing for circuits...
This requires a very clear definition of what the original [end to end]
user request expects in terms of payload. To take Guy's example of a
ethernet end point in GEANT and a handoff to I2 as a VCG... I suggest
that the model for this is really a tunnel. The user request asked that
the circuit use ethernet framing, this means that the actual user data
to be moved from end to end will be presented in the payload section of
the ethernet frame, presumeably at both ends. If those frames are
GFP'd inside a VCG, then the VCG must have a start and end point where
the GFP process encapsulates the data and unencapsulates it, or some
other protocol adapts the user data in the core and then reframes it in
ethernet frames at the end.
If GEANT elects to provision and progress that service request over a
VCG, then the VCG is actually a lower layer circuit across GEANT that
starts where the ethernet is adapted into the VCG. And then that VCG is
provisioned across the core and stitched to another lower layer circuit
across I2, all of which may or may not carry the ethernet frame in the
payload, but must at a minimum present the data at the user's specified
end point nside a ethenrnet frame. If GFP is used at the ends of the
VCG, then the ethernet framing is being tunneled whether or not the user
actually cares about the ethernet frames or just tthe paylaod data
itself. If, on the other hand, the Ethernet frame is opened up at the
VCG ingress, and only the ethernet payload is carried in the VCG frames,
then that is a different adaptation stage more akin to a stitching or
concatenation of two circuits with unlike framing - and the data could
conceivably be presented in different framing at the access port (on the
end).
I think this is a very important detail that we should be very clear
on: What does the user actually want moved from source to
destination...the ethernet frame itself? or the data inside the payload
section of the ethernet frame? And this gets a bit more complex when
you introduce VLAN taging at the ingress/egress. Once this is
understood, then it will define where the start of a circuit exists (or
maybe more appropriately - how to present the actual user data at the
termination points.)
The reason I dwell on this is that this detail seems to cause us a great
deal of confusion as we try to define these use cases.
We can provide any/all of these capabilites, but for the architecture to
be robust and well defined, we need to clear on what is the actual user
payload data to be moved end to end, and which parts of the transmission
protocols are simply transport containers that the network can
maniputlate to establish the end to end path.
Hope this was clear:-) and not too geeky.
Jerry
John Vollbrecht wrote:
> We will have a call tomorrow (Wed 6-24) at 9 ET.
> Call: +1-734-615-7474 (PSTN CALL-OUT DOES NOT WORK) or +1-866-411-0013
> (toll free US/Canada Only)
> Enter access code: 0155180
>
> We can discuss agenda at the beginning. Some suggestions
>
> A. documents sent out yesterday
> 1) revised use cases tp send to NML group - I sent yesterday
> 2) Pathfinding examples from Radek
> 3) request sequence diagrams from Guy
>
> B. Plans for document for next OGF
>
> C. Other issues - Joan's ideas for expanding Tomohiro's diagrams
> 1) describe how NSA's interoperate
> - request sequences, trust relations, topology sharing, monitoring
>
> other?
>
> John
>
>
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg
>
>
More information about the nsi-wg
mailing list