If the topological space on which a label is unique is reduced, ala
MPLS, to a one-hop link, and the label distribution is using TCP, ala
MPLS, the collision of the label space in case of LAN
partioning/healing is an interesting problem. It can be handled, I
think, assuming, the first and the last hop of a communication, in
several ways:
a. there is no collision because
- the label allocation continues undisturbed after
partitioning/healing, and
- only the originally LAN designated router does the allocation.
The "one-hop" TCP connection for Label Distribution that exists
between each host and the
LAN router in the pre-partioning stage, becomes a "two or more hops"
connection during the "partioned" stage, to come back to the
"one-hop" form after "healing".
b. at partitioning, the newly designated routers and their dependent
hosts do, ala MPLS:
- break old peering, with deallocation of labels
- create new peering, with reallocation of labels
at healing, the process is repeated.
This process affects only the next-hop to the host, and thus does not
affect the rest of the path.
c. designated routers divide the label space, as you said, to prevent
collision after potential partioning/healing.
Alex
Steve Deering wrote:
>
> At 7:21 PM +0100 12/1/00, Francis Dupont wrote:
> >In the future I can see two cases:
> > - the flow label is set by the source (first camp)
> > - the flow label is set by an edge router (with the DiffServ definition
> > of what is an edge router) because the source box (or its user) is
> > too dumb to deal with QoS/..., according to the edge router manager.
>
> If the Flow Label is set by something other than the source node, how
> do you guarantee its uniqueness, over the topological scope in which
> it must be unique? Do you need to invent a protocol between the routers
> on a LAN to divvy up the Flow label space? What happens when the LAN
> partitions, then routers in the different partitions assign duplicate
> Flow Labels, and then the partition heals?
>
> Steve
>
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page: http://playground.sun.com/ipng
> FTP archive: ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [EMAIL PROTECTED]
> --------------------------------------------------------------------
S/MIME Cryptographic Signature
