the ngni-mmi-qos (ipv6-qos) project: a brief presentation ... · interaction points introduction to...

The NGNI-MMI-QoS (IPv6-QoS) Project:A brief presentation on progress made so far

Rahul BanerjeeBirla Institute of Technology & Science (BITS), Pilani (India)

E-mail: [email protected] behalf of the NGNI-MMI-QoS Project-Team

(Partners: UPM,UoHA,UoB,Versaware,Telscom, Ericsson, BITS)The NGNI Infrastructure-QoS GroupNGNI 2002 Members Meeting

February 14, 2002 Brussels

Rahul BanerjeeBirla Institute of Technology & Science (BITS), Pilani (India)

E-mail: [email protected] behalf of the NGNIOn behalf of the NGNI--MMIMMI--QoS ProjectQoS Project--TeamTeam

(Partners: UPM,(Partners: UPM,UoHAUoHA,,UoBUoB,,VersawareVersaware,Telscom, Ericsson, BITS),Telscom, Ericsson, BITS)The NGNI Infrastructure-QoS GroupNGNI 2002 Members Meeting

February 14, 2002 Brussels

Interaction PointsIntroduction to the Project Objectives with specific reference to the IPv6-QoS activitiesA brief account of what has been done so far (D1 and D2)Approach taken towards projecting the IPv6-QoS Roadmap (D3)A brief technical overview of the Modified HbH-EH-based QoS solution A brief technical overview of the Modified FL Specification-based QoS Solution The road ahead … (D4)About the sequel project …Concluding remarks

Introduction to the Project With Specific Reference to the IPv6-QoS Activities

Focus: Evolving solutions relevant to the IPv6-level QoS issues, Standardization, Benchmarking and Technology Roadmap GenerationExpected Breakthroughs: Improved / New IPv6-specific QoS solutions, a resultant System Architecture, Benchmarking and Standardization Roadmaps (two Internet Drafts already published by the IETF)Significant Advantages: Modified Hop-by-Hop EH and Modified Flow Label Specification-based IPv6-specific QoS solutionsQoS solutionsabsence of which so far has not allowed real QoS advantages to be exploited, A carefully projected Technology RoadmapRoadmapthat should help the EC and others in deciding the future course of action.

Introduction to the Project … (contd.)

Deliverables: Four individual deliverables as applicable to respective focal points (D1 and D2 already delivered)Perceived Barriers : Multicast-QoS issues and Efficient DiffServ-IntServ Integration while retaining scalability …. To be addressed by the sequel project proposed by the same team ….Project websites: It has three sites: two external and one internal!– Official project site is: http://ipv6.bits-pilani.ac.in/ngni/ and – a mirror site is: http://www.bits-pilani.ac.in/~ngni/

(The first site is a fully IPv6-capable website whereas the second one is an IPv4-only site.) The project site has a link from the NGNI Website http://www.ngni.org/ as well. Project sites are maintained by BITS.

– An internal (for project-partners only) Collaboration Site is: https://mindit.dit.upm.es/. It is maintained by the UPM.

http://www.bits-pilani.ac.in/~ngni/

http://ipv6.bits-pilani.ac.in/ngni/


http://www.ngni.org/

https://mindit.dit.upm.es/

What has been done so far?

Deliverable ‘D1’ entitled: “Use of Various Parameters for Attaining QoS in IPv6-oriented Multimedia Internetworks“ has been submitted after three rounds of review. This is primarily an introductory document giving:– the different perspectives of the target area (a multi-

view survey), – a brief account of work-distribution within the team

and – an early discussion of one of the evolving QoS

solutions.


What has been done so far … (Contd.)

Deliverable ‘D2’ entitled: “Mechanisms for Attaining QoS in IPv6-oriented Multimedia Internetworks“ has been submitted after three rounds of review. This is a major document demonstrating the progress made towards the major objectives of the project. It gives details of two solutions to the target problem of IPv6-specific QoS; both of which have been submitted to the IETF e IETF as Internet Drafts.These IDs can be downloaded from the IETF’s website: //www.ietf.org/internet-drafts/ in .txt, .pdf and .ps versions. All these documents are also readily downloadable from the ct website. NGNI site has .pdf versions of ‘D1’ and ‘D2’ for


http://www.ietf.org/internet-drafts/


http://www.ngni.org/

What has been done so far … (Contd.)Also, a Searchable (meta-data-based) Repository has been created focused on the QoS-specific publicly available electronic documents around the world for consumption of the NGNI members and their associates.This facility is currently available in two forms:– With normal and advanced search on meta-data using HTML-PHP-

MySQL combination on a Linux Server with IPv6-support– With normal and advanced search on meta-data using HTML-ASP-

MS-SQL combination on a MS Windows 2000 Server with IPv4-only support.

Already over 5000 documents can be found (in all categories combined) through this engine. Facility is being further extended by BITS to provide support for Bibliography Generation and Intelligent Search.

http://ipv6.bits-pilani.ac.in/

Approach taken towards projecting the IPv6-QoS Roadmap (D3)

A three-stage IPv6-QoS Roadmap has been planned to evolve:– Stage-1: For next two years (of extreme immediate

importance in view of ongoing developments)– Stage-2: For further three years down the line (i.e. for

next five years)– Stage-3: For the next three years (as in CS, average

age of a generation of technology is not more than three years)

Approach taken towards projecting the IPv6-QoS Roadmap …

Focus of Roadmap Activity: Evolution of a balanced Technology Roadmap closely linked to a likely Business Roadmap using the identified technologiesMethodology Used: It is a five-step process involving:

• Identification of Key Themes (in IPv6-QoS)• Collection of Statistics through exhaustive survey for getting a feel of the

current status and using Simulation Modeling for generating data for future projections

• Validation of the projected Roadmap vis-à-vis technology and business trends• Selection of appropriate scenarios and supporting graphics for helping

the ‘Users of the Roadmap’ (say high-level strategic decision makers at the EC, industries and governments etc.) in quickly understanding the results

• Identification of Risk Factors and Likely Problems along the way (such that the Roadmap could be referred in a balanced way

A brief technical overview of QoS-Solution-1This solution

uses the Hop-by-Hop extension header in the IPv6 packet structureis based on the integrated services (IntServ)modeldoes not force use of the 20-bit Flow Label field of the Base Header so that it can act as a transitional or regular complement for this provision based QoSShall help in evolution of the FL field usageFor any QoS all routers need to share information about the resources.Hop-by-Hop header is processed through all the routers en-route to the destination.Information can be given in the TLV option Can be regarded as an ID-class document at present which after adequate discussion might become a full-fledged RFC subject toIETF’s approval.

A brief overview of QoS-Solution-1…

OptionHeader Ext LenNext Header

Option ValueOption Data LengthOption Type

Option Type : 8-bit identifier of the type of option.

Opt Data Len : 8-bit unsigned integer. Length of the Option Data field of this option, in octets.

Option Data : Variable-length field. Option-Type-specific data.




Options Data

00010000Header Ext LenNext Header

The source tells the routers that it is using the Integrated Services model by setting the nineteenth bit of the first 32 bits. (The Differentiated Services (DiffServ) feature can be exploited by setting the twentieth bit of the first 32 bits.)




Options Data


Two main Types of flows in the IntServ model are Guaranteed flowservice and Controlled Load Service

The Last 3 bits represent one of these types. Out of the eight possible combinations IntServ uses only two.




QoS identifier00000000Header Ext LenNext Header

The QoS Identifier is a 8 bit identifier and occupies the first byte in the options data field

It identifies the application’s per-flow specification.

This is a 8 bit identifier and occupies the first byte in the options data field

A brief overview of QoS-Solution-1…00000000Header Ext LenNext Header

Resource Identifier

QoS identifier

Resource Identifier: This is a 4-bit identifier field that specifies the type of the resource needed by a particular flow.

It follows the QoS Identifier in the option data field.This is followed by the amount of resource required in each type

The following gives the list of identified resource types0000 – End of List Identifier

This is a special identifier that specifies the end of the resource-required list0001 – Constant Data Transfer Rate

This identifies the Constant Bandwidth required and the value is given in a 32-bit field specified in Kbps (Kilo bits per second). (Max value = 512 GBps)

0010 – Average Data Transfer Rate This identifies the Average Bandwidth required and the value is given in a 32-

bit field in Kbps (Kilo bits per second).


Resource Identifier

QoS identifier

0011 – Maximum Data Transfer RateThis identifies the Maximum Bandwidth required and the value is given in a

32-bit field specified in Kilobits per second (Kbps).0100 – Minimum Delay Requirement

This identifies the Minimum Delay that the application demands and the required value is given in a 32-bit field specified in nanoseconds. (Max value = 4.3 sec)

0101 – Average Delay RequirementThis identifies the Average end-to-end delay that the application can tolerate

and the value is given in a 32-bit field specified in nanoseconds.0110 – Buffer Requirement

This identifies the Buffer Requirement by the flow at each router and the amount required is expressed as a 32-bit quantity specified in bytes. (Max value = 4 GB)


Resource Required ListQoS identifier

The Resource Required List:The Type of flow is specified in the option type bits.The 8 bits after the QoS identifier specify the required

resourcesThe resource identifiers are specified one after another.List ends with End of List identifier (0000).


Resource ID 00100110000032 bit value average bandwidth in bps

QoS identifier

32 bit value buffer required in bytes


Guaranteed Flow Service Specification Example has been shown above.

Similarly, the Controlled Load Service can be specified as shownbelow. Making bits 19-23 being zeros specifies no QoS requirement.

Resource Id. 0 0 1 0 0 1 1 0 0 0 0 032 bit value constant bandwidth in bps

QoS identifier

32 bit value (minimum delay in milliseconds)


A brief Overview of QoS-Solution-2

This solution suggests a modified specification for defining the 20-bit Flow Label field using a hybrid approach that includes options to provide IntServ as well as DiffServ-based support for Quality of Service. The resultant mechanism is fully workable and unambiguous as even the lower-level details have been worked out as may be required for real implementations.

A brief Overview of QoS-Solution-2 …Characteristics of IPv6 flows and Flow Labels as per the RFC 2460:

(a) A flow is uniquely identified by the combination of a source address and a non-zero Flow Label.

(b) Packets that do not belong to a flow carry a Flow Label of zero.(c) A Flow Label is assigned to a flow by the Flow's source node.(d) New Flow Labels must be chosen (psuedo) randomly and uniformly from the range 1 to FFFFF hex. The purpose of the random allocation is to make any set of bits within the Flow Label field suitable for use as a hash key by routers, for looking up the state associated with the flow.

A brief Overview of QoS-Solution-2 …Characteristics of IPv6 flows and Flow Labels ….

(e) All packets belonging to the same flow must be sent with the same source address, destination address, and Flow Label.

(f) If packets of flow include a Hop-by-Hop options header, then they all must be originated with the same Hop-by-Hop options header contents.(g) If packets of a flow include a routing header, then they all must be originated with the same contents in all extension headers up to and including the routing header.

A brief Overview of QoS-Solution-2 …

Characteristics of IPv6 flows and Flow Labels ….(h) The maximum's lifetime of any flow-handling state

established along a flow's path must be specified as part of the description of the state-establishment mechanism, e.g., the resource reservation protocol or the flow-setup hop-by-hop EH.

(i) The source must not reuse a Flow Label for a new flow within the maximum lifetime of any flow-handling state that might have been established for the prior use of that Flow Label.


Issues related with IPv6 Flow LabelThe IPv6 specification originally left open a number of questions, including:

• What should a router do with Flow Labels for which it has no state?

• What should the default action of the router be on receiving a datagram with a non-zero Flow Label for which it has no state information?

• Unknown Flow Labels may also occur if a router crashes and loses its state.

A brief Overview of QoS-Solution-2 …Issues related with IPv6 Flow Label …The IPv6 specification gives the following possible solutions to theseproblems:

• The routers can ignore the Flow Label.• IPv6 datagrams may carry flow-setup information in their

options.Additionally, as per the RFC 1809 and our view both, the default rule should be that if a router receives a datagram with an unknown Flow Label, it should treat the datagram as if the Flow Label is zero. As part of forwarding, the router will examine any hop-by-hop EH and learn if the datagram requires special handling. These options could include simply the information that the datagram is to be dropped if the Flow Label is unknown or could contain the flow state the router should have.

A brief Overview of QoS-Solution-2 …Issues related with IPv6 Flow Label …

How to flush old Flow Labels?RFC 1809 suggest a scheme employing a Timer.We suggest that:1. The MRU (Most Recently Used) algorithm should be used for

maintaining the Flow Labels. 2. Before flushing a label, the router should send an ICMP message to the source

saying that the particular label is going to be flushed. Therefore, the source should send a KEEPALIVE Message to the

router saying that not to flush the Flow Label in case the source requires the Flow Label to be used again.

On the other hand, if the source agrees with the router to delete the Flow Label, it should send a GOAHEAD Message to the router. On receiving the GOAHEAD Message, the router should immediately delete the label for that particular source. These messages are also sent to all the intermediate routers, so that, those routers can as well flush the Flow Labels for that particular source.


How to flush old Flow Labels …We suggest that …3. In case, the router does not receive any consent from the source, it will

resend the ICMP message for at most two or three times. If at all the router does not receive any reply from the source, it can flush that particular Label assuming that the Flow Label was not important enough for the source or any other intermediate router. The intermediate routers will also delete that Flow Label as they didn't receive any message from the source. The policy of sending the ICMP message to the source two or three times ensures the proper behaviour of the method of flushing Flow Labels in case of packet loss. This method assumes that the ICMP message would not be lost all thethree times as the probability of happening that is very less. Hence, if the router doesn't receive any reply from the source even after sending the ICMP message three times, it deletes the Flow Llabel.


Should the Flow Label be mutable or non-mutable, that is it should be read-only for routers or not?This work suggests that the Flow Labels should be non-mutable because of the following reasons:– Using mutable Flow Labels would require certain negotiation

mechanism between neighbouring routers, or a certain setupthrough router management or configuration, to make sure that the values or the changes made to the Flow Label are known to all the routers on the portion of the path of the packets, in which the Flow Label changes. On the other hand, the non-mutable Flow Labels certainly have the advantage of the simplicity implied by such acharacteristic.

– A mutable Flow Label characteristic goes against the IPv6 specification of the Flow Label explained in section 2 and the IPv6 Flow Label characteristics.


About use of Random Numbers in setting up the FL and Filtering using FL, this work concurs with Conta & Carpenter’s suggestions [draft-conta-ipv6-flow-label-02.txt] that the requirement of use of a Random Number in the FL field has to be relaxed.How to exactly define Flow Label specification so that it should resolve most of the referred issues and completes the specification for a subsequent implementation?– Conta & Carpenter have suggested five ways of doing so each

having its advantages and disadvantages discussed in detail in the Deliverable: ‘D2’.

– Consequently, this work suggests a hybrid approach for doing this.

A brief Overview of QoS-Solution-2 …We suggest that:

• As a hybrid approach is suggested in this document that includes various approaches already mentioned earlier in the previous slide, the management of the 20-bits in the IPv6 Flow Label becomes very critical.

• The 20-bits of the Flow Label should be defined in an appropriate manner so that the various approaches can be included to produce a more efficient hybrid solution. Hence, for this purpose, the first 3 bits of the IPv6 Flow Label are used to define the approach used and the next 17 bits are used to define the format used in a particular approach.

A brief Overview of QoS-Solution-2 …We suggest that …

• Following is the bit pattern for the first 3 bits of Flow Label that define the type of the approach used:

0 0 0 Default0 0 1 A random number is used to define the Flow Label.0 1 0 The value given in the Hop-by-Hop extension header is used instead the Flow Label.0 1 1 Multi Field Classifier is used.1 0 0 A format that includes the port number and the protocol in the Flow Label is used.1 0 1 A new definition explained later in a subsequent slide is

used.1 1 0 Reserved for future use.1 1 1 Reserved for future use.

• This definition of Flow Label includes IntServ and DiffServ and includes above mentioned options for defining Flow Label.


• For pseudo Random Number:0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|0 0 1| Pseudo - Random value |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• For Hop-by-Hop EH:0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|0 1 0| Don't care |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


• For Multi-Field Classifier:0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|0 1 1| DiffServ IPv6 Flow Label |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|0 1 1| Per Hop Behavior Identifier Code |R|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


• For Multi-Field Classifier:The classifier looks like:

C = (SA/SAPrefix, DA/DAPrefix, Flow-Label).Or

C` = (SA/SAPrefix, DA/DAPrefix, Flow-Label-Min: Range).

The range here specifies the difference between the maximum and the minimum Flow Label. The significance of using the range instead of Maximum Flow Label is the reduced number of bits. Definitely the difference between the two values can be specified in a lesser number of bits as compared to the value itself.


• Flow-Label-Classifier:IPv6SourceAddressValue/Prefix: 10:11:12:13:14:15:16:17:18::1/128IPv6DestAddressValue/Prefix: 1:2:3:4:5:6:7:8::2/128IPv6 Flow Label: 50

IPv6SourceAddressValue/Prefix: 10:11:12:13:14:15:16:17:18::1/128IPv6DestAddressValue/Prefix: 1:2:3:4:5:6:7:8::2/128IPv6 Flow Label:Range: 10:20

• Incoming Packet header (SA, DA, Flow Label) is matched against classification rules table entry (C or C`).


• Port Numbers should be defined as specified in [draft-conta-ipv6-flow-label-02.txt]; i.e., this approach reserves 16 bits for the port number and 1 bit for the protocol with the remaining bits reserved for the future use.

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|1 0 0| TCP Server port number |0|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|1 0 0| UDP Server port number |1|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• However our approach puts the restriction on the protocol to be used by any application since most of the applications seeking Real-time service use TCP or UDP as the transport layer protocol, this approach would work fine in most of the cases.

• In case the application requires to use any other host-to-host protocol, the other methods for specifying the Flow Label, discussed in other slides can be used.

A brief Overview of QoS-Solution-2 …A new structure and mechanism for the use of the Flow Label …

• By the optimal use of the bits in the Flow Label, this approach includes the various Quality of Service parameters in the IPv6 Flow Label that may be requested by any application. The variousQuality of Service parameters are:

1. Bandwidth2. Delay or Latency3. Jitter4. Packet Loss5. Buffer Requirements

• As packet loss and the jitter are always desired to be minimum by any application, these two parameters need not be defined in the Flow Label.


• Quality of Service parameters that are to be included in the Flow Label are:

1. Bandwidth (to be expressed in kbps).2. Delay (to be expressed in nanoseconds).3. Buffer requirements (to be expressed in bytes).

As there are only 17 bits left, the optimal use of the bits is very important so as to obtain the maximum information out of those 17 bits. The first bit out of these 17 bits is used to differentiate between the hard real time and soft real time applications. This bit is set to 0 for soft real time applications and it is set to 1 for hard real time applications.


A new structure and mechanism for the use of the Flow Label …

• After keeping one bit for Hard/Soft real time applications, we are left with 16 bits for defining the Flow Label. Let us see that how can we represent the values of bandwidth,delay and buffer requirements:

1. Bandwidth: This definition specifies 6 bits out of the 16 bits to be used forspecifying the bandwidth value. The application can demand for a minimum or a maximum value of bandwidth. So one bit out of these 6 bits is used for specifying whether the application is asking for a minimum value of bandwidth or a maximum.

0 - minimum expected value is specified.1 - maximum expected value is specified.



• After keeping ….. how can we represent the values of bandwidth,delay and buffer requirements:

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|1 0 1|0| Flow Label |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In the above bit sequence, the application uses this new definition for defining the Flow Label, as described by the first 3 bits. The application is a hard real time, as evident by the 4th bit. It asks for a minimum bandwidth of value that will be described in the nextfew bits.



The 5 bits for the bandwidth can be exploited in two ways as shownbelow:Approach 1: This approach uses a simple formula to calculate the bandwidth fromthe five bits. The following values of bandwidths can be obtained for various bit-sequences.

00000 - 32 kbps00001 - 64 kbps.00111 - 4 mbps.01111 - 1 gbps.11111 - 64 tbps

The formula used here to calculate the bandwidth in decimal fromthe bit pattern is: Bandwidth (in decimal) = 2^B * 32 where B is the decimal equivalent of the bandwidth specified in 5 bits.



The 5 bits for the bandwidth can be exploited in two ways as shownbelow …Approach 2: This approach uses a lookup table that maps the value mentioned inthe bandwidth field of the Flow Label to the value already defined in the lookup table. These values have to be universally accepted and uniformly defined in all the routers and end-nodes.

In the opinion of the authors, using first approach will result in saving the time for lookup in providing the quality of service. In event of the requirement of certain intermediate values, the second approach could be used. However whichever alternative is used, it shall be recommended in the final version of this specification to use only one of these approaches, preferably the former.




2. Buffer RequirementsThis definition specifies 6 bits out of the 16 bits to be used forspecifying the buffer value.00000 - 512 bytes00001 - 1 kbytes.00111 - 64 kbytes.01111 - 16 mbytes.11111 - 1 tbytesThe formula used here to calculate the buffer in decimal from the bit pattern is:Buffer (in decimal) = 2^B * 512 where B is the decimal equivalent of the buffer specified in 5 bits.



3. DelayThis definition specifies 5 bits out of the 16 bits to be used for specifying the delay value. The application can tolerate a specified value of delay. So the five bits left for the delay value can be used in the following manner:

00000 - 4 nanoseconds00001 - 8 nanoseconds.

01000 - 1 microseconds.11111 - 8 seconds

The formula used here to calculate the buffer in decimal from the bit pattern is: Delay (in decimal) = 2^B * 4 nanoseconds where B is the decimal equivalent of the delay specified in 5 bits.


A new structure and mechanism for the use of the Flow Label …Concluding Remarks..– This work has dealt extensively with all the suggested formats for

defining the 20-bit IPv6 Flow Label and finally has suggested a hybrid approach for efficiently defining the 20-bit IPv6 Flow Label.

– The emphasis of this work is to result into a practically acceptable specification that could be effectively used for a reasonably long period of time for implementing IPv6 Quality of Service that so far has been elusive in absence of a clear, verifiable and complete specification.

Roadmap to Future

Consequent to discussions and experimentation, further refinement of these solutions to IPv6-QoS and attempt for attaining a possible RFC status after IETF-WG and IESG examine their suitability as per their well-established procedure.Defining the next two Deliverables ‘D3’ and ‘D4’ in light of these and other new and existing knowledge -- in terms of Benchmarking, Roadmap-derivation and Standardization respectively.

What Next? About the Sequel…

Consequent to successful completion of this activity, a sequel project-activity has been proposed by the same set of NGNI-partners.Known as the “Project Bridge”, this project-activity aims at attempting to address the Multimedia Multicast-specific IPv6-QoS issues and evolving a workable mechanism for providing a scalable and manageable QoS solution. As a natural consequence, this sequel would also produce documents leading to Standardization, Benchmarking and Roadmaps --- in keeping with the objectives of the NGNI.

References[RFC 2460] RFC 2460, Internet Protocol version 6 Specification.[RFC 2117] RFC 2117, Router Alert Option in IPv6.[Paul et al] QoS in Data Networks, Protocols and Standards byArindam Paul.[RFC 2676] RFC 2676, QoS Routing Mechanisms and OSPF Extensions.[NGNI-MMI-QoS: D1-v-1.3] Rahul Banerjee (BITS), Juan Quemda(UPM), P. Lorenz (UHA), Torsten Braun (UoB), Bernardo Martinez (Versaware): "Use of Various Parameters for Attaining QoS in IPv6-based Multimedia Internetworks", Nov. 2001.[NGNI-MMI-QoS: D2-v1.3] Rahul Banerjee (BITS), Juan Quemda(UPM), P. Lorenz (UHA), Torsten Braun (UoB), Bernardo Martinez (Versaware): “New Mechanisms for Attaining QoS in IPv6-based Multimedia Internetworks", Feb. 2002.Several IDs (including draft-conta, draft-banerjee-*) and RFCs (including RFC 1809), in addition, have helped in the preparation of this draft.

Any questions please?

Thank You!

the ngni-mmi-qos (ipv6-qos) project: a brief presentation ... · interaction points introduction to...

Documents