SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : The *NEW* Frank Coluccio Technology Forum

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: Frank A. Coluccio who wrote (32)6/5/2000 12:31:00 AM
From: ftth  Read Replies (2) of 46821
 
I guess it started with my inquiry on FSAN, with this being the first mention: Message 13803065

I read the Monterey article; it sounds conceptually similar to what CA*net3 is trying to accomplish, no?

It's not exactly what I had in mind, but I'm sure they've put a hell of a lot more man-hours into thinking about it than I've put into the scheme I had in mind. However, they really never address (in the article anyway) what these Lambda's *are* in that article, or how they are grouped, and how/where to translate from that grouping into a destination route. But that's the tricky part so maybe they want to keep that under wraps.

What I was thinking might be best described by analogy to a hard disk. You have some umpteen-gigabyte hard drive on your computer and you freely create directories and subdirectories (which would be analogous to the class hierarchy I spoke of, assuming there was some logical structure to the directory tree).

You drop files into these directories and subdirectories without any care regarding the size of the file. This would be analogous to the infinite (for all practical purposes) capacity of a lambda for a single end-user class stream.

You don't have to pre-provision the subdirectory "bandwidth" before using it to plop a file into it. Likewise with the class hierarchy of lambdas. The contents of a lambda would be analogous to the file you plop into a subdirectory.

The lambda class would be traceable to some root/parent class (and this would have to be standardized because this is what the core routers use to determine how to route the "second half" of the journey to the destination). The core routers don't need to know or care how or what derived classes the stream contains. They just route based on the standardized parent class it was derived from (along with some cataloging information contained as a class descriptor in the lambda "header").

To provision a lambda for a local transport stream you derive it from the "standardized" parent classes. This would be analogous to either creating a subdirectory on the disk, or plopping the file into an already-existing/predefined subdirectory.

What you call it and how you derive it only has to be known in your local AS. Once the stream goes outside the AS, it's only known by the parent class.

This could become a seriously long post if I continue, and I can't claim I've got it all worked out by any stretch, but does this give a better idea where I'm trying to go?
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext