Packet transfer method and node device using resource...

Electrical computers and digital processing systems: multicomput – Distributed data processing

Reexamination Certificate

Rate now

  [ 0.00 ] – not rated yet Voters 0   Comments 0

Details

C709S200000, C709S203000, C709S205000, C709S213000, C709S238000, C370S235000, C370S397000, C370S400000, C370S409000

Reexamination Certificate

active

06336129

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to a packet transfer method and a node device for providing a constant level of communication quality in a packet communication network.
2. Description of the Background Art
In the packet communication network such as IP (Internet Protocol) network, for example, a router determines an output link by searching through a routing table at a time of packet transfer. This routing table search requires a relatively large processing amount so that it tends to be the bottleneck in improving the router speed.
In order to resolve this bottleneck, there are propositions of a new packet transfer schemes. For example, in the router called CSR (Cell Switch Router), one VC (Virtual Connection) of ATM or the like is provided for each group of packet flows that are to be transferred by the same route and a correspondence between that VC and the packet flows that flow through there is notified to neighboring CSRs (this operation will be referred to as a protocol for VC set up). The cells from the input VC can be sent to the output VC without reassembling them into IP packets, by storing the correspondence between the input VC and the corresponding output VC for each packet flow. Hereafter, this packet transfer will be referred to as the cut-through transfer. In this cut-through transfer, there is no need to search out the output link for each IP packet from the routing table so that it is possible to realize a high speed packet transfer.
Also, in the router called LSR (Label Switch Router), a value called label is written between an IP packet header and a datalink packet header, for instance, where different labels are used for different packet flows that share the same route, even in the case of using the connectionless datalink media such as Ethernet. The LSR can determine the output link and the output label value from the label value of the received packet, by storing a correspondence between the input label and the corresponding output label value and output link. In this way, similarly as in the CSR, the IP packet transfer is carried out without the IP processing such as IP routing table search. Namely, in the LSR, a virtual channel is set up even in the connectionless datalink media by using the label, and the packet transfer without the Ip processing is carried out according to an identifier (that is the label) of this virtual channel. Hereafter, a path through which the packet is transferred without the IP processing by using the label will be referred to as an LSP (label Switched Path).
Now, an exemplary case of using ATM as the datalink layer media used in the LSR will be described, but as already mentioned above, it is possible to set up a virtual channel by using the concept of the label even in the case of using the connectionless data link media such as Ethernet, so that the same description as in the case of ATM also holds in such a case.
When the flow is defined as a group of packets which have the same set of (destination address, destination port number, protocol number, source address, source port number), the LSR sets up one VC with respect to a group of flows which share the same route. For example, one VC is set up for the purpose of transferring flow groups which have the same set of (destination address, source address). In this way, it is possible to reduce the necessary number of VCs than the case of setting up one VC for each flow. Else, by setting up one VC for the purpose of transferring flow groups which have the same set of (destination network address, source network address), it is possible to reduce the necessary number of VCs further. Else, it is also possible to set up one VC for the purpose of transferring flow groups which have the same edge router as an ingress node of some domain and the same destination network address, or to set up one VC for the purpose of transferring flow groups which have the same edge routers as ingress and egress nodes of some domain.
Here, an exemplary case of the cut-through transfer with respect to the multicast flow will be described with reference to FIG.
8
.
FIG. 8
shows a situation in which a transmitting terminal
501
and receiving terminals
601
and
602
are connected to an LSR network (domain)
901
formed by four LSRs
701
to
704
, through communication channels
101
to
103
respectively. The communication channels
101
to
103
are channels for connecting edge LSRs of the LSR network with communication devices external to the LSR network. Each of these channels may not necessarily be a physically single channel and can be a virtual communication channel formed by the router network, for example. Also, VCs
801
to
803
are set up on the communication channels among the LSRs
701
to
704
. Each of these channels between the LSRs also may not necessarily be a physically single channel and can be a virtual communication network formed by the ATM network.
The transmitting terminal
501
is transmitting a multicast flow A, a multicast flow B, and a multicast flow C, and the receiving terminals
601
and
602
are receiving these multicast flows. Here, the flows A, B and C are assumed to have the same destination multicast address and source address, but at least one of the destination port number, the source port number and the protocol number is different among them.
In
FIG. 8
, the ingress LSR
701
of the LSR network
901
is transferring packets belonging to the flows A, B and C to the VC
801
, and the next hop LSR
702
is carrying out the cut-through transfer by outputting cells from the input VC
801
to the output VCs
802
and
803
.
Now, in the connectionless network such as IP network, for example, the amount of delay exerted on packets becomes larger when the amount of packets that arrive at a router for carrying out the packet transfer becomes larger. However, in this case, each terminal is entrusted to make the judgement as to whether or not to reduce the load on the router by limiting the amount of packets transmitted by the terminal, and each terminal has no obligation to limit the amount of packets it transmits. This is because IP is designed without any consideration for the guarantee of the communication quality. For this reason, in the IP network, it is normally impossible to guarantee the communication quality with respect to a user. However, in order to carry out the video communication, for instance, it is necessary to guarantee the communication quality such as packet transfer delay, and for this reason there are active discussions about the way of guaranteeing the communication quality in the IP network.
For example, in the standardization organization called IETF, a scheme for notifying a necessary bandwidth called RSVP (Resource ReSerVation Protocol) has been proposed. This scheme uses seven types of control messages including Path message. Resv message, PathTear message, ResvTear message, PathErr message, ResvErr message, and Confirmation message. The basic operation of RSVP is that the transmitting terminal notifies the transmission traffic characteristic to the network and the receiving terminal using the control message called Path message, and the receiving terminal notifies a necessary bandwidth to the network using the control message called Resv message. When values in fields of Path message are inappropriate, the network transmits PathErr message, and when values in fields of Resv message are inappropriate, the network transmits ResvErr message. Also, by transmitting PathTear message from a transmitting side node (the transmitting terminal or a router) or ResvTear message from a receiving side node (the receiving terminal or a router), it is possible to delete the reserved bandwidth immediately. In RSVP, the transmission of Path message and Resv message is carried out regularly in order to deal with a change of communication route by the network and a malfunction of a router.
Now, flows of Path message and Resv message in RSVP will be described with reference to
FIGS. 9A and 9B
.
FIG. 9A

LandOfFree

Say what you really think

Search LandOfFree.com for the USA inventors and patents. Rate them and share your experience with other people.

Rating

Packet transfer method and node device using resource... does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Packet transfer method and node device using resource..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Packet transfer method and node device using resource... will most certainly appreciate the feedback.

Rate now

     

Profile ID: LFUS-PAI-O-2856654

  Search
All data on this website is collected from public sources. Our data reflects the most accurate information available at the time of publication.