[Mycolleagues] 1st CfP: MMEDIA 2009 | The First International Conference on Advances in Multimedia | Colmar, France, on July 19 -24, 2009

_______________________________________________
Mycolleagues mailing list
Mycolleagues <at> grid.lrg.ufsc.br
http://grid.lrg.ufsc.br/mailman/listinfo/mycolleagues

[Mycolleagues] CFP: Journal of Annals of Telecommunications - Special issue on VIRTUALIZATION: TOWARS VIRTUALIZATION AT INTERNET SCALES

_______________________________________________
Mycolleagues mailing list
Mycolleagues <at> grid.lrg.ufsc.br
http://grid.lrg.ufsc.br/mailman/listinfo/mycolleagues

Call for Participation - SIGMETRICS '06 (June 26-30, 2006 at Saint Malo)- Early registration deadline May 31

APOLOGIES FOR MULTIPLE COPIES

**** Early registration : before May 31 *********

Call for Participation:  SIGMETRICS/Performance 2006 Joint International Conference on 
Measurement and Modeling of Computer Systems

June 26th-30th 2006, Saint-Malo, France

http://www.cs.wm.edu/sigm06/

We cordially invite you to attend the joint SIGMETRICS/Performance 
Conference held in beautiful Saint-Malo, which will bring together 
researchers from academia and industry.  The conference covers 
state-of-the-art, analytic, simulation, and measurement-based 
performance evaluation techniques applied to all areas of 
computer-science and engineering.

Highlights:

* A strong single-track technical program, held in the Palais du Grand Large

* Keynote address by Professor Dan Reed, University of North Carolina, 
Director of the Renaissance Computing Institute, on "Performance and 
Reliability: The Ubiquitous Challenge"

* Broad and exciting workshop and tutorial programs preceding the main 
conference.

Full details are on the conference Web site.

Important dates:

* Early Registration Deadline:  May 31,  
http://www.cs.wm.edu/sigm06/register.html

* Student Travel Grants Deadline: May 10, 
http://www.cs.wm.edu/sigm06/students.html

* Workshops:  June 26-27, 2006

* Tutorials:  June 26-27, 2006 

* Main Conference: June 28-30, 2006

Raymond Marie, SIGMETRICS 2006 General Chair

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt

Re: RSVP-TE: specifying links in EROs

This is what I thought.  I also thought that using ERO subobjects with 
/32 addresses matching interface addresses would work.  But I can't find 
anything in the RFCs that documents this behavior.

I also thought the IF-ID subobject (used for unnumbered links) would 
work, but the RFC says otherwise.  It says only that the subobject can 
be used to define an abstract node via router-ID and IF-ID, and says 
that the actual ERO processing does not change from what was previously 
documented.

-- David

Don Fedyk wrote:
> Hi David
> 
> It was my impression that if you use numbered links, the ERO could
> specify the links as well. 
> 
> Don 
> 
> 
> 
> 
>>-----Original Message-----
>>From: owner-te-wg <at> ops.ietf.org 
>>
>>I've been reading through RFCs 3209, 3473, and 3477.
>>
>>I can't seem to find any mechanism that an originating node 
>>can use to 
>>fully specify both the nodes and links of an ERO.  All the discussion 
>>deals with abstract nodes, and doesn't say a thing about how 
>>to select 
>>specific links between the nodes.
>>
>>Clearly, the chosen link must satisfy the LSP's constraints 
>>(QoS, CoS, 
>>link colors, etc.), but when there are multiple compatible links, the 
>>RFCs appear to be silent.
>>
>>If an originating node wishes to fully specify the path through the 
>>network, down to the granularity of individual links, is there an 
>>RFC-specifie behavior that will allow this?
>>
>>One can obviously build RSVP-TE with rules to permit this (such as 
>>selecting interfaces that exactly match ERO subobjects when 
>>there is a 
>>compatible match), but I can't find anything in the RFCs that discuss 
>>this.  They all merely state that the subobjects define 
>>abstract nodes 
>>(which may be a single router), but with no more granularity 
>>than that.
>>
>>Surely, given the requirements and design goals of GMPLS, 
>>there must be 
>>a mechanism that I've missed.  Can anyone help?
>>
>>-- David
>>
>>
>>
>>
>>

RSVP-TE: specifying links in EROs

I've been reading through RFCs 3209, 3473, and 3477.

I can't seem to find any mechanism that an originating node can use to 
fully specify both the nodes and links of an ERO.  All the discussion 
deals with abstract nodes, and doesn't say a thing about how to select 
specific links between the nodes.

Clearly, the chosen link must satisfy the LSP's constraints (QoS, CoS, 
link colors, etc.), but when there are multiple compatible links, the 
RFCs appear to be silent.

If an originating node wishes to fully specify the path through the 
network, down to the granularity of individual links, is there an 
RFC-specifie behavior that will allow this?

One can obviously build RSVP-TE with rules to permit this (such as 
selecting interfaces that exactly match ERO subobjects when there is a 
compatible match), but I can't find anything in the RFCs that discuss 
this.  They all merely state that the subobjects define abstract nodes 
(which may be a single router), but with no more granularity than that.

Surely, given the requirements and design goals of GMPLS, there must be 
a mechanism that I've missed.  Can anyone help?

-- David

RFC 4216 on MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements

A new Request for Comments is now available in online RFC libraries.

        RFC 4216

        Title:      MPLS Inter-Autonomous System (AS)
                    Traffic Engineering (TE) Requirements
        Author(s):  R. Zhang, Ed., J.-P. Vasseur, Ed.
        Status:     Informational
        Date:       November 2005
        Mailbox:    raymond_zhang <at> infonet.com, jpv <at> cisco.com
        Pages:      29
        Characters: 64640
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-tewg-interas-mpls-te-req-09.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc4216.txt

This document discusses requirements for the support of inter-AS
MPLS Traffic Engineering (MPLS TE).  Its main objective is to
present a set of requirements and scenarios which would result in
general guidelines for the definition, selection, and specification
development for any technical solution(s) meeting these requirements
and supporting the scenarios.

This document is a product of the Internet Traffic Engineering Working
Group of the IETF.

This memo provides information for the Internet community.  It does
not specify an Internet standard of any kind.  Distribution of this
memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST <at> IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST <at> RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info <at> RFC-EDITOR.ORG with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info <at> RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager <at> RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
RFC-EDITOR <at> RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

_______________________________________________
IETF-Announce mailing list
IETF-Announce <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce

Re:

+----------------------------------------------------+

Panda GateDefender has detected malicious content (Virus) in the following file: [Garry.cpl]
W32/Bagle.AH.worm

The file has been deleted to protect the network.
07/18/2005 08:08 +0100

www.pandasoftware.com

+----------------------------------------------------+

RFC 4125 on Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering

A new Request for Comments is now available in online RFC libraries.

        RFC 4125

        Title:      Maximum Allocation Bandwidth Constraints Model for
                    Diffserv-aware MPLS Traffic Engineering
        Author(s):  F. Le Faucheur, W. Lai
        Status:     Experimental
        Date:       June 2005
        Mailbox:    flefauch <at> cisco.com, wlai <at> att.com
        Pages:      12
        Characters: 22585
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-tewg-diff-te-mam-04.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc4125.txt

This document provides specifications for one Bandwidth Constraints
Model for Diffserv-aware MPLS Traffic Engineering, which is referred
to as the Maximum Allocation Model.

This document is a product of the Internet Traffic Engineering Working
Group of the IETF.

This memo defines an Experimental Protocol for the Internet community.
It does not specify an Internet standard of any kind.  Discussion and
suggestions for improvement are requested.  Distribution of this memo
is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST <at> IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST <at> RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info <at> RFC-EDITOR.ORG with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info <at> RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager <at> RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
RFC-EDITOR <at> RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

_______________________________________________
IETF-Announce mailing list
IETF-Announce <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce

RFC 4127 on Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering

A new Request for Comments is now available in online RFC libraries.

        RFC 4127

        Title:      Russian Dolls Bandwidth Constraints Model for
                    Diffserv-aware MPLS Traffic Engineering
        Author(s):  F. Le Faucheur, Ed.
        Status:     Experimental
        Date:       June 2005
        Mailbox:    flefauch <at> cisco.com
        Pages:      13
        Characters: 23694
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-tewg-diff-te-russian-07.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc4127.txt

This document provides specifications for one Bandwidth Constraints
Model for Diffserv-aware MPLS Traffic Engineering, which is referred
to as the Russian Dolls Model.

This document is a product of the Internet Traffic Engineering Working
Group of the IETF.

This memo defines an Experimental Protocol for the Internet community.
It does not specify an Internet standard of any kind.  Discussion and
suggestions for improvement are requested.  Distribution of this memo
is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST <at> IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST <at> RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info <at> RFC-EDITOR.ORG with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info <at> RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager <at> RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
RFC-EDITOR <at> RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

_______________________________________________
IETF-Announce mailing list
IETF-Announce <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce

RFC 4126 on Max Allocation with Reservation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering & Performance Comparisons

A new Request for Comments is now available in online RFC libraries.

        RFC 4126

        Title:      Max Allocation with Reservation Bandwidth
                    Constraints Model for Diffserv-aware MPLS Traffic
                    Engineering & Performance Comparisons
        Author(s):  J. Ash
        Status:     Experimental
        Date:       June 2005
        Mailbox:    gash <at> att.com
        Pages:      22
        Characters: 51232
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-tewg-diff-te-mar-06.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc4126.txt

This document complements the Diffserv-aware MPLS Traffic Engineering
(DS-TE) requirements document by giving a functional specification for
the Maximum Allocation with Reservation (MAR) Bandwidth Constraints
Model.  Assumptions, applicability, and examples of the operation of 
the MAR Bandwidth Constraints Model are presented.  MAR performance is
analyzed relative to the criteria for selecting a Bandwidth
Constraints Model, in order to provide guidance to user implementation
of the model in their networks.

This document is a product of the Internet Traffic Engineering Working
Group of the IETF.

This memo defines an Experimental Protocol for the Internet community.
It does not specify an Internet standard of any kind.  Discussion and
suggestions for improvement are requested.  Distribution of this memo
is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST <at> IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST <at> RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info <at> RFC-EDITOR.ORG with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info <at> RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager <at> RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
RFC-EDITOR <at> RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

_______________________________________________
IETF-Announce mailing list
IETF-Announce <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce

RFC 4124 on Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering

A new Request for Comments is now available in online RFC libraries.

        RFC 4124

        Title:      Protocol Extensions for Support of
                    Diffserv-aware MPLS Traffic Engineering
        Author(s):  F. Le Faucheur, Ed.
        Status:     Standards Track
        Date:       June 2005
        Mailbox:    flefauch <at> cisco.com
        Pages:      37
        Characters: 79265
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-tewg-diff-te-proto-08.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc4124.txt

This document specifies the protocol extensions for support of
Diffserv-aware MPLS Traffic Engineering (DS-TE).  This
includes generalization of the semantics of a number of Interior
Gateway Protocol (IGP) extensions already defined for existing MPLS
Traffic Engineering in RFC 3630, RFC 3784, and additional IGP
extensions beyond those.  This also includes extensions to RSVP-TE
signaling beyond those already specified in RFC 3209 for existing MPLS
Traffic Engineering.  These extensions address the requirements for
DS-TE spelled out in RFC 3564. 

This document is a product of the Internet Traffic Engineering Working
Group of the IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST <at> IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST <at> RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info <at> RFC-EDITOR.ORG with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info <at> RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager <at> RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
RFC-EDITOR <at> RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

_______________________________________________
IETF-Announce mailing list
IETF-Announce <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce