KR20130136530A - 원격 서버에 질의하는 것에 의한 플로우 라우팅 프로토콜 - Google Patents

원격 서버에 질의하는 것에 의한 플로우 라우팅 프로토콜 Download PDF

Info

Publication number
KR20130136530A
KR20130136530A KR1020137026799A KR20137026799A KR20130136530A KR 20130136530 A KR20130136530 A KR 20130136530A KR 1020137026799 A KR1020137026799 A KR 1020137026799A KR 20137026799 A KR20137026799 A KR 20137026799A KR 20130136530 A KR20130136530 A KR 20130136530A
Authority
KR
South Korea
Prior art keywords
communication host
server
flow
host
routing information
Prior art date
Application number
KR1020137026799A
Other languages
English (en)
Inventor
브루노 몬자존-카자베트
프랑소와 타부레트
Original Assignee
알까뗄 루슨트
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 알까뗄 루슨트 filed Critical 알까뗄 루슨트
Publication of KR20130136530A publication Critical patent/KR20130136530A/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0893—Assignment of logical groups to network elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0894—Policy-based network configuration management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5019—Ensuring fulfilment of SLA
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/302—Route determination based on requested QoS
    • H04L45/306—Route determination based on the nature of the carried application
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/38—Flow based routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/24—Connectivity information management, e.g. connectivity discovery or connectivity update
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5007—Internet protocol [IP] addresses
    • H04L61/5014—Internet protocol [IP] addresses using dynamic host configuration protocol [DHCP] or bootstrap protocol [BOOTP]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

통신 호스트(H)에 의해 데이터 패킷으로 구성된 플로우(FF, FH)를 전송하기 위한 방법으로서, 통신 호스트(H)는 플로우의 전송을 인에이블링하는 출력 포인트의 세트(p1, p2, p3)를 소유하고, 플로우는 플로우의 특성에 의해 판단되는 라우팅 정보에 기초하여 출력 포인트의 세트 중에서 하나의 포인트로 라우팅되며, 방법은 또한 라우팅 정보의 적어도 일부를 수신하기 위해 원격 서버(SA, SB)에 질의하는 단계를 포함한다.

Description

원격 서버에 질의하는 것에 의한 플로우 라우팅 프로토콜{FLOW ROUTING PROTOCOL BY QUERYING A REMOTE SERVER}
본 발명은 인터넷 통신 네트워크에서의 플로우 라우팅에 관한 것이다. 이러한 통신 네트워크는 TCP/IP 프로토콜 스위트(suite)에 의존한다.
역사적으로, 통신 네트워크는 패킷 라우팅에 기반해 왔다: 각 패킷은 마지막 수신처에 도달할 때까지 네트워크 내에서 독립적으로 라우팅되며, 마지막 수신처는 최초 데이터(initial data)를 재구성하기 위해 패킷을 정확히 어셈블링할 책임이 있다. 따라서, 전송된 데이터의 종류(nature)와 라우팅 사이의 커넥션이 존재하지 않는다.
특히 트래픽의 종류(비디오 스트림, HTTP 트랜잭션 등) 및 액세스 네트워크(Wi-Fi, 3G, 이더넷, 펨토셀 등)에 기초하여, 다른 것과 분리하여 임의의 타입의 트래픽을 구별하기 위해 이러한 커넥션을 생성할 필요에 이르렀다.
이러한 필요는 개별적으로 고려된 패킷보다는 패킷 플로우에 기초한 입도(granularity)로 라우팅을 개선하는데 사용될 수 있는 메커니즘의 패밀리의 생성으로 이어졌다. 이러한 메커니즘은 일반적으로 "IP 플로우 라우팅"이라 칭한다.
이들은 특히 무선 액세스 기술에 적용된다. 그러한 네트워크의 오퍼레이터는 한 타입의 트래픽만을 전송하기 원할 수 있다. 예를 들어, IEEE 802.11 표준에 명시되어 있는 바와 같이, LTE("롱 텀 에볼루션(Long Term Evolution") 네트워크는 HTTP(Hyper Text Transfer Protocol) 트래픽 보다는 VOIP(voice over IP) 트래픽을 전송하는 것에 대한 선호를 나타낼 수 있는 반면, 반대의 선택이 Wi-Fi 네트워크에 대하여 행해질 수 있다.
호스트 자체는 데이터 플로우를 전송하기 위해 다른 것보다 하나의 액세스 네트워크를 선택하도록 이러한 결정을 할 필요가 있을 수 있다. 예를 들어, 2-모드 통신 단말은 음성 또는 비디오 트래픽에 대하여 LTE 액세스 네트워크를 우선순위로 제공할 수 있고 다른 타입의 트래픽에 대하여 Wi-Fi 액세스 네트워크를 제공할 수 있다.
플로우의 타입에 기초한 라우팅의 이러한 제어 및 판단은 일부 오퍼레이팅 시스템, 가령 "Linux Advanced Routing and Traffic Control(LARTC)" 모듈과 함께 가능하다. 도 1은 LARTC에 의해 제공되는 메커니즘에 관한 도면이다.
호스트(H)는 두 개의 액세스 네트워크(AN1 및 AN2)와 인터페이싱한다. 액세스 네트워크는 그들 자신의 인터넷 네트워크(N)에 접속된다. 호스트(H)는 액세스 네트워크(AN1)와의 인터페이스(IF1) 및 액세스 네트워크(AN2)와의 인터페이스(IF2)를 소유한다.
따라서, 호스트(H)는 액세스 네트워크(AN1, AN2) 중 하나에 의해 인터넷 네트워크(N)와 통신할 수 있다.
호스트(H) 내 이러한 액세스 네트워크 각각과 연관된 라우팅 테이블뿐만 아니라 라우팅 테이블 중 하나 또는 다른 것이 사용될 상황을 정의하는 라우팅 규칙을 정의하는 것이 가능하다. 이러한 메커니즘들은, 예를 들어, 웹사이트:http://lartc.ora/howto/lartc.rpdb. multiple - links . html에 설명되어 있다.
추가적으로, 링크: http://linux-ip.net/html/linux-ip.html는 섹션 4.9에서 리눅스 커널(Linux kernel) 내 라우팅 정책을 설명한다.
그러나, 이 옵션은 홀로 액세스 네트워크의 오퍼레이터의 요구사항을 완전히 충족시키기에 불충분하다. 이것은 규칙 및 라우팅 테이블이 호스트(H) 내에서 구성되는 정적 메커니즘이다. 이러한 규칙 및 라우팅 테이블에 대한 변경은 단지 호스트에 의존하는 방식으로 및 국부적으로 행해질 수 있다: 규칙의 포맷, 구성 인터페이스 등은 호스트의 동작 시스템에 따라 그리고 구현예에 따라 상이하다.
따라서, 본 발명은 액세스 네트워크의 오퍼레이터로 하여금 호스트에 의해 사용되는 라우팅 정책을 제어가능하도록 함으로써 상황을 개선하는 것이 목적이다.
국제 특허 출원 WO 2010/097057 호는 호스트에 대하여 의도된 라우팅 정보를 포함하는 것이 가능하도록 만드는 DHCP 프로토콜의 확장을 제안한다.
그럼에도 불구하고, 그러한 접근법은 DHCP 클라이언트 및 서버가 동작할 수 있도록 변경하는 것을 요구한다. 따라서 이의 전개 비용은 많은 이동통신 이해관계자에게 있어 매우 높은 비용이다.
그러므로 본 발명은 기존 프로토콜 계층을 변경할 필요가 없는 대안을 제안하는 것을 포함하며, 이에 따라 본 발명은 통신 네트워크의 구현에 있어 최소 비용을 갖는다.
그렇게 하기 위해, 본 발명의 첫 번째 목적은 통신 호스트에 의해 데이터 패킷으로 구성된 플로우를 전송하기 위한 방법으로, 통신 호스트는 플로우의 전송을 인에이블링하는 출력 포인트의 세트를 소유하고, 플로우는 플로우의 특성에 의해 판단되는 라우팅 정보에 기초하여 출력 포인트 세트 중에서 하나의 포인트로 라우팅된다.
또한 이 방법은,
- 동적 구성 서버로부터 오는 응답 메시지에서 원격 서버의 식별자를 수신하는 단계와,
- 라우팅 정보의 적어도 일부를 수신하기 위해 원격 서버에 질의하는 단계를 포함한다.
본 발명의 일 실시예에 따라, 이 방법은,
- 원격 서버가 통신 호스트로 통지 메시지를 전송하는 단계 ― 통지 메시지는 라우팅 정보를 포함하고 통신 호스트에 의해 요청되지 않음 ― 와,
- 통신 호스트가 통지 메시지 내 포함된 라우팅 정보에 기초하여 자신의 라우팅 정보를 업데이트하는 단계를 포함한다.
이 방법은 통신 호스트가 원격 서버와 연관된 액세스 네트워크에 접속할 때 트리거된 원격 서버를 판단하는 이전 단계를 포함한다.
식별자의 수신 이후에, 통신 호스트는 식별자를 분석하고 IP 어드레스를 획득하기 위해 (DNS 타입의) 도메인 이름 서버에 질의할 수 있다.
본 발명의 추가 목적은 통신 호스트로서, 통신 호스트는
- 데이터 패킷으로 구성된 플로우의 전송을 인에이블링하는 출력 포인트의 세트,
- 라우팅 정보가 들어있는 메모리,
- 플로우의 특성에 의해 판단된 라우팅 정보에 기초하여 출력 포인트의 세트 중 하나의 출력 포인트에 플로우를 전달하기 위한 라우팅 디바이스를 구비하고,
- 통신 호스트는 동적 구성 서버로부터 오는 응답 메시지 내 원격 서버의 식별자를 수신하도록 동작하고,
- 통신 호스트는 라우팅 정보의 적어도 일부를 원격 서버로부터 수신하는 프로토콜 클라이언트를 추가적으로 포함한다.
이 방식으로, 라우팅 정책 서버는 액세스 네트워크의 오퍼레이터에 의해 호스팅되고 제어될 수 있으며, 이는 이로써 호스트에 의해 사용된 정책 및 규칙에 대한 완전한 제어를 갖는다. 이러한 호스트는 특히 동적으로 관리될 수 있는데: 오퍼레이터의 서버의 임의의 업데이트는 호스트에 오는 임의의 새로운 라우팅 정책 요청에 즉시 영향을 미친다.
또한, 라우팅 정책은 액세스 네트워크에 의해 사용된 프로토콜 스택 위에서 통신된다. 따라서 이 통신은 호스트 상에 배치된 오퍼레이팅 시스템에 더 이상 의존하지 않는다.
이것이 오퍼레이터의 중요한 바램이라는 사실 외에, 또한 라우팅 정책의 제어를 그들에게 허용하는 것에는 다른 이점이 존재하는데, 그들은, 정적 관점(기술, 구성 등) 및 동적 관점(부하 측정, QoS 등) 모두로부터, 어떤 네트워크가 전송할 수 있는지 또는 전송할 수 없는지에 관한 더 나은 관점을 갖는다.
추가적으로, 본 발명은 전용 서버 및 프로토콜 스택의 구현, 및 특정 프로토콜의 정의에 기초한다. 본 발명은 임의의 방법으로 종래 프로토콜 스택(그리고 특히 DHCP 클라이언트 및 서버)을 수정하지 않는다. 또한 본 발명은 본 발명의 목적에 필요한 파라미터 및 요소만이 관리되도록 하기 때문에 간단한 구현을 가능하게 하는 반면, 본 기술 분야의 DHCP와 같은 종래 프로토콜의 확장은 이들이 문제를 해결하는데 기여하지 않더라도 프로토콜의 요구사항을 따르는 것이 필요하다.
본 발명의 다른 이점 및 특성은, 첨부된 도면과 관련되어 이어지는 실시예들에 관한 설명에서 더 분명히 명백해질 것이다.
도 1은 이미 언급된 최근 기술을 구현하는 아키텍처에 관한 도해를 제공한다.
도 2는 본 발명을 지원하는 네트워크 아키텍처뿐만 아니라 본 발명에 따른 통신 호스트에 대한 하나의 가능한 기능적 아키텍처에 관한 도해이다.
도 3은 발명적 방법을 예증하는 시간 그래프를 도시한다.
도 4는 본 발명의 일 실시예에 따라, DHCP 및 DNS 서버를 통합하는 네트워크 아키텍처를 도시한다.
도 5는 상기 실시예에 관한 시간 그래프를 도시한다.
일반적으로 말해서, IP 호스트는 복수의 출력 포인트를 포함할 수 있다. 이러한 출력 포인트 각각은 IP 어드레스와 관련된다. 이러한 출력 포인트는 인터페이스에 속하며, 각 인터페이스는 잠재적으로 하나 이상의 출력 포인트를 갖는다.
도 2의 예시에서, 통신 호스트(H)는 두 개의 액세스 네트워크(NA 및 NB)에 의해 코어 네트워크(N)에 접속된다. 통신 호스트는 각 액세스 네트워크 대한 두 개의 통신 인터페이스(IFA, IFB)를 포함한다. 제 1 인터페이스(IFA)는 두 개의 다른 IP 어드레스에 대응하는 두 개의 출력 포인트(P1, P2)를 포함한다. 제 2 인터페이스(IFB)는 하나의 IP 어드레스에 대응하는 단일 출력 포인트(P3)를 포함한다.
나머지 설명에서, 이러한 인터페이스 내 입력 포인트들은 본 발명의 관점에서 특정 역할을 하지 않기 때문에, 이들의 존재는 언급되지 않을 것이다.
알려진 방식 그 자체로, 통신 호스트(H)는 라우팅 디바이스(R) 및 프로토콜 클라이언트(HTTPc, FTPc) 등을 포함한다. 라우팅 디바이스의 역할은, 프로토콜 클라이언트로부터 라우팅 포인트(P1, P2, P3) 중 하나에 데이터 패킷 플로우를 보내는 것이다.
이 플로우 라우팅은 패킷 플로우에 대하여 실행되고, 고려된 각 패킷에 대하여 개별적으로 실행되지 않는다. 이를 위해, 라우팅 디바이스(R)는 데이터 플로우의 특성을 추출한다. 이 추출은 라우팅 패킷을 위해 사용된 "수신처 어드레스" 및 "수신처 포트" 헤더를 넘어선다.
각 패킷 플로우에 대하여 판단되거나 추출될 특성은 통신 호스트(H)의 메모리(P) 내에 포함된 라우팅 정보에 의존할 수 있다.
데이터 패킷 플로우를 선택하는데 사용될 수 있는 필드를 정의하고자 하는 일부 작업이 있다. 예를 들어, RFC 2280 "Routing Policy Specification Language" 및 RFC 6080 "Traffic Selectors for Flow Bindings"가 인용될 수 있다.
플로우의 제 1 패킷 특성을 판단하고 및 라우팅 규칙에 의해 설정된 조건을 충족하는지 판단하기 위해서, 딥 추출(deep extraction)이 플로우의 제 1 패킷에 대해서만 전적으로 실행될 수 있다. 후속 패킷에 대하여, 이것이 플로우에 속하는지를 판단하는 것이 충분할 수 있다. 그렇게 하기 위해, 더 제한된 수의 IP 패킷의 헤더에 관한 분석은 충분할 수 있다. 일반적으로, 그러한 식별은, 소스 및 수신처 어드레스 및 포트, 뿐만 아니라 사용된 프로토콜의 식별자(즉, TCP, UDP 등)로 형성된 5-튜플(5-tuple)에 기초하여 실행될 수 있다.
본 발명의 일 실시예에 따라, 라우팅 정보는 라우팅 테이블 및 라우팅 규칙으로 구성될 수 있다.
복수의 라우팅 테이블은 이로써 라우팅 디바이스(R)에 대하여 이용가능할 수 있다. 라우팅 규칙은, 패킷 플로우의 특성에 따라, 어느 라우팅 테이블이 적용되는지 나타낼 수 있다.
특성들은 패킷의 헤더로부터 직접적 또는 간접적으로 도출된다. 이러한 헤더는 전반적으로 IP 계층의 헤더이지만, 더 복잡한 메커니즘이 구현될 수 있는데 이는 다른 프로토콜 계층이 탐색되는(explored) 것을 요구한다.
이러한 기술은 용어 "딥 패킷 검사(Deep Packet Inspection: DPI)"로 알려진 기술일 수 있으며, 이는 패킷의 내용물을 탐색하기 위해 IP 헤더를 넘어서는 것을 포함한다.
또한 이것은 복수의 헤더를 종합하거나 하나 이상의 헤더로부터 파생되는 특성을 판단하는 것이 가능할 수 있다.
리눅스 동작 시스템의 "어드밴스드 라우팅(Advanced Routing)"에 기초한 일 실시예에서, 이러한 규칙들은 "라우팅 정책 데이터베이스(Routing Policy Databace: RPDB)"로 알려진 메모리(P)의 일부에 저장된다. 규칙은 라우팅 다바이스(R)가 라우팅 테이블에서 검색을 수행하는 순서를 제어한다. 각 규칙은 우선순위를 갖는다.
플로우의 제 1 패킷이 송신될 때, 라우팅 프로토콜(R)은 우선순위의 순서로 모든 규칙에 걸쳐 브라우징하고, "if" 부분이 라우팅될 플로우에 의해 만족되는 규칙을 조우할 때 이 브라우징을 중단한다.
그 이후 라우팅 디바이스는 규칙을 적용한다. 일반적으로, 이는 규칙에 의해 지정된 특정 라우팅 테이블을 사용하는 것 및 라우트(route)를 찾아 이를 검색하는 것을 수반하지만, 다른 옵션 또한 가능하다.
프로토콜 특성에 기반한 플로우 라우팅의 예
도 2의 예시에서, 두 개의 프로토콜 클라이언트(HTTPc 및 FTPc)는 두 프로토콜 서버(HTTPs 및 FTPs) 데이터 패킷 플로우를 각각 송신하고, 응답으로 데이터 플로우를 수신할 수 있고, 이는 또한 HTTP 및 FTP 프로토콜을 준수한다.
이들의 데이터 패킷 플로우를 전송하기 위해, 두 개의 프로토콜 클라이언트 (HTTPc 및 FTPc)는 라우팅 디바이스(R)와 통신한다.
라우팅 정보는 이러한 두 플로우를 다르게 라우팅하도록 메모리(P) 내에 제공되었다. 이 라우팅 정보는 규칙의 형태, 잠재적으로는 라우팅 테이블의 형태를 취할 수 있다.
예를 들어, 메모리(P)는 다음의 두 규칙을 포함할 수 있다(이해를 위해 의사-자연어(pseudo-natural language)로 표시됨):
- IF 프로토콜=HTTP; 라우트=IFA
- IF 프로토콜=FTP; 라우트=IFB
이러한 두 개의 규칙은, HTTP 세션에 대응하는 플로우가 인터페이스 IFA로 라우팅되어 액세스 네트워크(NA)에 의해 서버(HTTPs)에 도달할 것이라는 것과, FTP 플로우가 IFB 인터페이스로 라우팅되어 액세스 네트워크(NB)를 통해 서버(FTPs)에 도달할 것임을 표현한다.
다른 실시예는 메모리(P) 내에서 두 개의 규칙 및 두 개의 라우팅 테이블(TH 및 TF)을 가지는 것을 포함한다.
두 개의 규칙은 다음과 같은 포맷을 가질 수 있다:
- IF 프로토콜=HTTP; 라우트=TH
- IF 프로토콜=FTP; 라우트=TF
이 구현예는, 출력 인터페이스를 표시하는 것이 아니라 사용될 라우팅 테이블을 나타내는 것을 가능하게 한다: HTTP 프로토콜에 대한 테이블 TH, 및 FTP 프로토콜에 대한 테이블 TF.
물론, 메모리(P)에 관한 다른 실시예들 및 구조가 가능하다.
주어진 플로우에 의해 사용된 프로토콜에 관한 판단은 IP 헤더의 "프로토콜" 필드 값을 판단함으로써 실행될 수 있다.
이로써 액세스 네트워크(NA 및 NB)의 기술적 특성 및 이점을 최적으로 고려하여, 다른 방법으로 FTP 트래픽 및 HTTP 트래픽을 라우팅하는 것이 가능하다.
규칙 서버에 질의( HRP 프로토콜)
더욱이, 호스트(H)는 원격 서버(SA, SB)로부터 메모리(P) 내 저장된 라우팅 정보의 적어도 일부를 수신하기 위해 프로토콜 클라이언트(HRPc)를 갖는다.
라우팅 정보가 다른 수단에 의해 메모리(P) 내에 저장되는 것 및 라우팅 정보의 일부만이 하나 이상의 원격 서버로부터 온다는 것이 규정될 수 있다.
바람직한 실시예에 따라, 각 액세스 네트워크에 대하여 하나의 서버가 있다. 이 방법으로, 각 네트워크 오퍼레이터는 자신의 서버를 제어하고, 이로써 통신 호스트에 전송되는 라우팅 정보를 관리한다. 이 방식으로, 도 2의 예시에서, 액세스 네트워크(NA)는 서버(SA)와 연관되고 액세스 네트워크(NB)는 서버(SB)와 연관된다.
서버(SA, SB)는 통신 호스트로부터 요청을 수신하고 그러한 호스트에 응답을 송신하기 위해 통상적으로 인터페이스를 갖는다. 서버는 라우팅 정보를 출력 포인트 식별자와(즉, 일반적으로 IP 어드레스와) 연관시키는 데이터베이스를 추가적으로 갖는다.
도 3은 본 발명의 프로토콜의 전형적인 구현 사이클을 도시한다.
이 프로토콜은 "호스트 라우팅 정책(Host Routing Policy)", 즉 HRP로 지칭될 수 있다. 이는 여러 타입의 메시지: 요청 메시지, 응답 메시지, 및 잠재적으로 통지 메시지로 구성된다.
이러한 메시지들은 상이한 전송 프로토콜, 가령 UDP 또는 TCP에 의해 전송될 수 있다.
우선, 통신 호스트(H)의 프로토콜 클라이언트(HRPc)는 자신의 출력 포인트(p1)에 대하여 서버(SA)로 메시지(M1)를 전송한다.
이 메시지는 메시지 타입의 식별자를 포함할 수 있다. 이 식별자는 본 발명의 HRP 프로토콜과 관련된 요청인지를 간단히 나타낼 수 있다.
메시지는 요청과 통신 호스트(H)에 의한 응답 사이의 연관성을 인에이블링하는 교환 식별자를 포함할 수 있다.
메시지는 또한 다른 파라미터들을 포함할 수 있다.
예를 들어, 파라미터는 요청이 통신 호스트로부터 나오는 것임을 나타낼 수 있다. 사실, 서버가 다른 서버에 질의하는데 동일한 프로토콜을 사용할 수 있다는 것, 및 이로써 서버가 라우팅 정보를 교환한다는 것이 제공될 수 있다.
이는 부하를 균형있게 하기 위해 동일한 액세스 네트워크에 대하여 복수의 서버를 용이하게 가지는 것이 가능하도록 만들 수 있다. 이로써 업데이트는 서버들 사이의 질의 메커니즘에 의해 모든 서버들에 분배될 수 있다.
서버는 심지어 다른 서버의 전체 데이터베이스를 복사하기 위해, 특히 부팅 시, 잠재적으로 다른 서버에 질의할 수 있다.
메시지(M1)가 수신될 때, 서버(SA)는 메시지(M1)가 호스트(H)에 의해 송신되었던 출력 포인트(p1)의 식별자를 사용할 수 있다. 이 식별자는 단순히, 메시지(M1)를 요약(encapsulating)하는 IP 패킷의 "소스 어드레스" 헤더 내에 포함된, IP 어드레스일 수 있다.
다른 식별자들이 사용될 수 있다. 특히, 식별자는 통신 호스트(H)에 의해 판단될 수 있고 요청 메시지(M1)의 파라미터로서 전송될 수 있다.
식별자에 기초하여, 서버(SA)는 연관된 라우팅 정보를 검색하기 위해 데이터베이스에 질의할 수 있다. 이 라우팅 정보는 통신 호스트(H)에 대한 응답으로서 직접 사용될 수 있고, 또는 호스트에 대한 응답으로서 제공되는 제 2 정보가 도출될 수 있는 제 1 정보를 제공할 수 있다. 서버가 제 1 정보 "템플릿" 및 호스트의 출력 포인트의 식별자에 기초하여 즉시 라우팅 정보를 도출하거나 구축하는 프로세싱 디바이스를 가지는 것이 제공될 수 있다.
통신 호스트(H)로 송신된 응답(M2)은 다음을 포함할 수 있다:
- 메시지 타입의 식별자. 이 식별자는 HRP 프로토콜의 응답 메시지인지를 나타낼 수 있음.
- 메시지(M1) 내 포함된 것과 동일해야 하는 교환 식별자(an exchange identifier). 이로써 통신 호스트는 두 메시지(M1 및 M2)를 연관시킬 수 있고 수신된 메시지(M2)가 송신 메시지(M1)에 응답인 것을 이해할 수 있음.
- 라우팅 정보.
이 라우팅 정보는 복수의 응답 메시지(M2)에 걸쳐 분배될 수 있다. 그렇다면, 각 응답 메시지는 동일한 교환 식별자를 포함해야 한다. 이들은 또한 다른 응답 메시지가 이어진다는 것을 나타내는 플래그(a flag)를 포함할 수 있다.
메시지(M2)(또는 그러한 메시지들)가 수신될 때, 프로토콜 클라이언트(HRPc)는 업데이트(U1)를 메모리(P)에 송신한다. 도 3에서, 메모리(P)는 간략화를 위해 라우팅 디바이스(R)와 조합된다.
본 발명의 일 실시예에 따라, 라우팅 정보는 규칙일 수 있다. 이러한 규칙은 무엇이 해당 인터페이스 포인트 상에서 권한을 부여받는지만을 정의할 수 있다. 따라서, 디폴트로, 규칙에 의해 명시적으로 권한 부여되지 않은 때에는 언제나 금지된다.
호스트(H)는 수신된 정보를 상이한 방법으로 구조화할 수 있다. 특히, 호스트는 수신된 라우팅 정보의 전부 또는 일부를 라우팅 테이블 형태로 구조화할 수 있다.
바람직한 실시예에 따라, 서버로의 요청은 통신 호스트(H)의 각 출력 포인트(p1, p2, p3)에 대하여 송신될 수 있다.
따라서 프로토콜 클라이언트(HRPc)는 또한 출력 포인트(p2)에 대한 다른 요청 메시지를 동일한 서버(SA)에 송신할 수 있다. 이 메시지뿐만 아니라 응답 메시지는 도 3에 도시되지 않는다. 이들은 메시지(M1 및 M2)와 유사하고 내용 값에 의해 다르다.
프로토콜 클라이언트(HRPc)는, 인터페이스(IFB)에 속한 제 3 출력 포인트(p2)에 대해 다른 요청 메시지(M3)를 송신한다. 이 요청은 액세스 네트워크(NB)와 연관된 서버(SB)에 송신된다. 이 서버(SB)는, 서버(SA)와 유사하고, 데이터베이스에 기초하여 판단되는 라우팅 정보를 포함하는 응답 메시지(M4)와 함께 통신 호스트(H)에 응답한다.
이 응답 메시지(M4)가 수신될 때, 프로토콜 클라이언트(HRPc)는 라우팅 디바이스(R)와 연관된 메모리(P)에 업데이트(U2)를 송신한다.
이 라우팅 디바이스(R)는 그 이후 업데이트된 라우팅 정보와 함께 플로우를 프로세싱할 수 있다.
도 2 및 3의 예시에서, 서버(SA)가 HTTP 트래픽을 수락한다는 것을 명시하는 규칙을 전송하는 것이 가정된다. 그러는 동안, 서버(SB)는 FTP 트래픽을 수락한다는 것을 명시하는 규칙을 전송한다.
그러한 규칙들은 다음과 같은 포맷을 가질 수 있다:
IF 프로토콜=FTP; 라우트=IFB/p3
IF 프로토콜=http; 라우트=IFA/p1
그러므로 라우팅 디바이스는 FTP 플로우(FF)를 출력 포인트(p3)로 전송한다. 이는 코어 네트워크(N) 및 서버(FTPs)에 도달하기 전에 액세스 네트워크(NB)를 거친다. HTTP 플로우(FH)는 출력 포인트(p1)로 라우팅된다. 이것은 코어 네트워크(N) 및 서버(HTTPs)에 도달하기 전에 액세스 네트워크(NA)를 거친다.
본 발명의 일 실시예에서, 호스트(H)는 이러한 상이한 출력 포인트를 통해 서버로 전달되는 라우팅 정보의 일관성과 관련된 문제를 해결하기 위한 수단을 가질 수 있다.
통지( Notification )
또한, 서버(SA, SB)는 호스트의 요청에 의하지 않고, 통신 호스트에 라우팅 정보를 전송할 수 있다. 대부분의 경우 통신 호스트가 액세스 네트워크에 접속할 때 이러한 요청을 전송한다고 믿어지지만, 액세스 네트워크의 오퍼레이터가 이들의 라우팅 정책에 변경을 행하고 서버와 연관된 데이터베이스를 수정할 수 있다는 것 또한 제공될 수 있다.
이러한 관점에서, HRP 프로토콜은 통지 메시지를 포함할 수 있다. 통지 메시지는, 통신 호스트에 의해 요청되지 않고, 서버의 결단(a server`s initiative)으로 전송된다는 것으로 특징지어진다. 통지 메시지는 특정 하나의 호스트 또는 서버의 알려진 호스트 모두로 전송될 수 있다.
후자의 경우, 일 구현예는 이 메커니즘을 위한 특정 멀티캐스트 어드레스로 통지를 전송하는 것을 포함할 수 있다. 다른 구현예는, 서버가 메시지를 교환하는 통신 호스트의 어드레스를 저장하기 위해, 그리고 글로벌 통지가 송신되어야 할 때 이를 참고하기 위해 서버 내에 메모리를 가지도록 구성된다.
도 3의 예시에서, 서버(SA)는 통지 메시지(M5)를 통신 호스트(H)에 송신한다.
이 통지 메시지는 다음을 포함할 수 있다:
- 메시지 타입의 식별자. 이 식별자는 통지 메시지가 HRP 프로토콜의 통지 메시지인지를 나타낼 수 있음.
- 라우팅 정보.
- 통지의 목적(예를 들어, 추가 또는 삭제)을 설명하는 이벤트 타입.
통지 메시지가 수신될 때, 프로토콜 클라이언트(HRPc)는 메모리(R)의 업데이트(U3)를 송신할 수 있다.
라우팅 규칙 서버를 판단
통신 호스트(H)가 라우팅 정보를 획득할 수 있는 서버(SA, SB)의 어드레스를 알 수 있도록 하기 위해 다수의 구현예들이 가능하다.
서버의 어드레스(또는 다른 식별)는 호스트의 관리자에 의해 국부적으로 구성될 수 있다.
다른 구현예들은 사전결정된 멀티캐스트 어드레스에 대한 요청을 송신하는 통신 호스트를 포함할 수 있고 이로써 서버는 요청에 대하여 응답할 수 있고 호스트-서버 접속을 수립할 수 있다. 이 요청은 통신 호스트(H)가 액세스 네트워크(NA, NB)에 접속할 때 송신될 수 있다.
다른 구현예는 동적 어드레스 할당 서버로부터 오는 응답 메시지 내에서 원격 서버의 식별자를 획득하는 것을 포함할 수 있다.
그러한 구현예는 도 4에 의해 예증된다. 도 4는 도 2에 의해 묘사된 디바이스를 반복하고, 동적 구성 서버(DHCPA, DHCPB), 및 도메인 이름 서버(DNSA, DNSB)를 추가한다.
이러한 동적 구성 서버는 일반적으로 RFC 2131, "동적 호스트 구성 프로토콜(Dynamic Host Configuration Protocol)"을 준수한다. 그러한 서버는 일반적으로 용어 "DHCP 서버"로 알려져 있다.
동적 구성 서버(DHCP)는, 전형적으로 관리자 또는 심지어 호스트의 사용자의 중재 없이, 호스트를 동적으로 투명하게(transparently) 구성하는 것이 가능하게 만드는데 사용된다. 호스트가 통신 네트워크에 접속할 때, 표준화된 교환은 호스트(H)로 하여금 통신 네트워크와 통신하는데 필요한 정보를 자동으로 획득하도록 한다. 필수 정보는 전반적으로 호스트가 통신을 위해 사용해야 하는 IP 어드레스를 포함한다.
본 발명에 따라, 이러한 메커니즘 및 이러한 타입의 서버의 사용 덕분에, 호스트(H)는 또한 원격 서버(SA, SB)의 식별자를 획득할 수 있다.
도 5는 호스트(H) 및 액세스 네트워크(NA) 사이의 교환을 도시한다. 동일한 타입의 교환이 액세스 네트워크(NB)와 함께 도입된다.
제 1 메시지(MD1)는 호스트(H) 내 포함된 프로토콜 클라이언트(DHCPc)에 의해 서버(DHCPA)로 송신될 수 있다. 이 메시지(MD1)는 호스트(H)가 액세스 네트워크(NA)에 접속할 때 전송될 수 있다. 이는 RFC 2131에 따라 DHCP 프로토콜에 따른 "DISCOVER" 메시지일 수 있다.
응답으로, 서버(DHCPA)는 호스트(H)가 액세스 네트워크(NA)와 통신하는데 사용할 수 있는 IP 어드레스를 포함하는 메시지(MD2)를 전송한다.
프로토콜 클라이언트(DHCPc)는 그 이후, 이 IP 어드레스를 사용하여 메시지(MD3)를 전송할 수 있고, 이 메시지는 원격 서버의 식별자를 원한다는 것을 명시하는 옵션 필드(an option field)를 포함한다. 이 옵션 필드는 문자 스트링(a character string)이다. 공중 통신망에서 본 발명을 효율적으로 사용하기 위해, 이 옵션 필드는 IANA와 함께 파일링된 표준화 요청의 대상이어야 한다. 이 스트링은, 예를 들어, IETF의 RFC 4703에서 정의되는 FQDN 프로토콜인, HRP-FQDN-OPT일 수 있다.
알려진 방식 자체에서, 메시지는 또한 DNS(Domain Name Server)의 식별자를 원한다는 것을 명시하는 옵션 필드를 포함할 수 있다.
이 메시지는 RFC 2131에 따른 "REQUEST" 메시지일 수 있다.
동적 구성 서버(DHCPA)는 그 이후 응답 메시지(MD4)를 송신할 수 있다. 이 응답 메시지는 RFC 2131에 따른 "REPLY" 메시지일 수 있다. 이 응답 메시지는 DNS의 식별자(예를 들어, 이의 IP 어드레스)를 포함할 수 있다.
이는 또한 원격 서버(SA)의 식별자를 포함할 수 있다. 이 식별자는 원격 서버(SA)의 IP 어드레스일 수 있다. 이는 대안적으로 IETF의 RFC 1035에 따른 FQND(Fully Qualified Domain Name) 논리적 식별자일 수 있다.
이 식별자는 DHCP 프로토콜에 따라 MD4 메시지의 옵션 필드 내에 포함될 수 있다. 이 필드는 "REPLY" 메시지의 "HRP FQND Option" 필드일 수 있다. 이는 필드의 식별자, 길이, 및 값을 포함할 수 있다. 이 값은 제목 "Domain Names - Implementation and Specification"인 IETF의 RFC 1035의 권고를 준수할 수 있다.
구성 서버(DHCPA)가 본 발명에 따라 이 확장을 관리하도록 동작하지 않는 경우, 또는 호스트에 대하여 이용가능한 정보가 없는 경우, 예를 들어, 메시지(MD4) 내 어떤 "HRP FQDN Option"도 반환하지 않거나 널 길이(a null length)를 가진 "HRP FQDN Option" 필드를 반환할 수 있다.
호스트(H)가 구성 서버(DHCPA)에 대한 후속 요청 내에 "HRP FQDN Option" 필드를 포함하는 것이 가능하다. 이 경우, 구성 서버는 값을 반환할 수 있고, 이 값은 잠재적으로 다른 이유로(액세스 네트워크(NA)의 재구성 등) 초기 값과 다를 수 있다.
이 메시지(MD4)가 수신될 때, 프로토콜 클라이언트(DHCPc)는 수신된 FQDN 식별자를 분석하기 위해 도메인 이름 서버(DNSA)(이의 식별자는 구성 서버(DHCPA)에 의해 이전에 제공되었음)에 요청(MD5)을 송신할 수 있다.
통상적으로, 이름 서버(DNSA)는 FQDN 식별자에 대응하는 IP 어드레스를 포함하는 응답 메시지(MD6)를 반환한다.
프로토콜 클라이언트(DHCPc)는 수신된 IP 어드레스를 통신 호스트(H)의 내부의 메시지(MD7)에 의해 프로토콜 클라이언트(HRPc)로 송신할 수 있다. 이 내부 메시지의 포맷은 호스트(H)의 아키텍처 및 다양한 프로토콜 클라이언트의 API 프로그래밍 인터페이스에 따라 다르다. 다른 구현예들이 가능하고 본 기술분야의 당업자에게 용이하게 접근가능하다.
그 이후 프로토콜 클라이언트(HRPc)는, 도 3에 대하여 이미 설명된 바와 같이, 원격 서버(SA)에 요청(M1)을 전송할 수 있고, 응답(M2)을 수신하고 업데이트 메시지(U1)를 통해 메모리(P)를 업데이트할 수 있다. 이미 언급된 바와 같이, 동일한 교환이 액세스 네트워크(NB)에 대하여 이뤄질 수 있다.
일반적으로 말해서, Ipv4에서, 옵션 필드 "HRP FQDN", 또는 균등한 것이, 통신 호스트에 의해 DHCP 메시지 "Discover" 및 "Request"에 삽입될 수 있다. 동적 구성 서버(DHCP)는 원격 서버의 식별자(및 필드 길이)를 나타내는 값을 포함하는 "HRP FQDN" 옵션 필드를 통신 호스트(H)에 송신된 DHCP "Reply" 메시지 내에 삽입할 수 있다.
Ipv6에서, 클라이언트는 "간청(Solicit)", "요청(Request)", "갱신(Renew)", "리바인드(rebind)", "정보_요청(Information-Request)" 및 "재구성(Reconfigure)" 메시지에, IETF의 RFC 3315에 의해 정의된 바와 같이, "OPTION_IA_HRP_FQDN" 옵션을 DHCPv6 옵션 요청 옵션 헤더에 삽입할 수 있다.
동적 구성 서버(DHCP)는, (IANA에 의해 표준화되어야 하는) 옵션 코드, 필드 길이, 및 식별자를 나타내는 값을 포함하는 특정 옵션 필드에 원격 서버의 식별자를 삽입할 수 있다.

Claims (7)

  1. 통신 호스트(H)에 의해, 데이터 패킷으로 구성된 플로우(FF, FH)를 전송하기 위한 방법 ― 상기 통신 호스트(H)는 상기 플로우의 전송을 인에이블링하는 출력 포인트의 세트(p1, p2, p3)를 소유하고, 상기 플로우는 상기 플로우의 특성에 의해 판단되는 라우팅 정보에 기초하여 상기 출력 포인트의 세트 중에서 하나의 포인트로 라우팅됨 ― 으로서, 상기 방법은
    동적 구성 서버(DHCPA, DHCPB)로부터의 응답 메시지 내에서 원격 서버(SA, SB)의 식별자를 수신하는 단계와,
    상기 라우팅 정보의 적어도 일부를 수신하기 위해 상기 원격 서버(SA, SB)에 질의(querying)하는 단계를 포함하는
    플로우 전송 방법.
  2. 제 1 항에 있어서,
    상기 원격 서버가 상기 통신 호스트로 통지 메시지를 전송하는 단계 ― 상기 통지 메시지는 라우팅 정보를 포함하고 상기 통신 호스트에 의해 요청되지 않음 ― 와,
    상기 통신 호스트가 상기 통지 메시지 내 포함된 상기 라우팅 정보에 기초하여 자신의 라우팅 정보를 업데이트하는 단계를 더 포함하는
    플로우 전송 방법.
  3. 재 1 항 또는 제 2 항에 있어서,
    상기 통신 호스트(H)가 상기 원격 서버와 연관된 액세스 네트워크와 접속할 때 트리거된 상기 원격 서버(SA, SB)를 판단하는 이전 단계를 포함하는
    플로우 전송 방법.
  4. 제 1 항 내지 제 3 항 중 어느 한 항에 있어서,
    상기 식별자를 수신한 이후에, 상기 통신 호스트는 상기 식별자를 분석(resolve)하고 IP 어드레스를 획득하기 위해 도메인 이름 서버(DNSA, DNSB)에 질의하는
    플로우 전송 방법.
  5. 데이터 패킷으로 구성된 플로우(FF, FH)의 전송을 인에이블링하는 출력 포인트의 세트(p1, p2, p3), 라우팅 정보가 들어있는 메모리(P), 및 상기 플로우의 특성에 의해 판단된 라우팅 정보에 기초하여 상기 출력 포인트의 세트 중 하나의 출력 포인트에 상기 플로우를 전달하기 위한 라우팅 디바이스(R)를 포함하는 통신 호스트(H)로서, 상기 통신 호스트는
    동적 구성 서버(DHCPA, DHCPB)로부터 오는 응답 메시지 내 원격 서버(SA, SB)의 식별자를 수신하도록 동작하고,
    상기 라우팅 정보의 적어도 일부를 상기 원격 서버로부터 수신하는 프로토콜 클라이언트를 추가적으로 포함하는
    통신 호스트.
  6. 제 5 항에 있어서,
    상기 통신 호스트(H)가 상기 원격 서버와 연관된 액세스 네트워크에 접속할 때 상기 원격 서버(SA, SB)를 판단하도록 동작하는
    통신 호스트.
  7. 제 5 항 또는 제 6 항에 있어서,
    상기 식별자를 수신한 이후에, 상기 식별자를 분석하고 IP 어드레스를 획득하기 위해 도메인 이름 서버(DNSA, SNSB)에 질의하도록 동작하는
    통신 호스트.
KR1020137026799A 2011-04-11 2012-03-02 원격 서버에 질의하는 것에 의한 플로우 라우팅 프로토콜 KR20130136530A (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR1153133A FR2973976B1 (fr) 2011-04-11 2011-04-11 Protocole pour routage de flots par interrogation d'un serveur distant
FR1153133 2011-04-11
PCT/EP2012/053649 WO2012139819A1 (en) 2011-04-11 2012-03-02 Flow routing protocol by querying a remote server

Publications (1)

Publication Number Publication Date
KR20130136530A true KR20130136530A (ko) 2013-12-12

Family

ID=44279017

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020137026799A KR20130136530A (ko) 2011-04-11 2012-03-02 원격 서버에 질의하는 것에 의한 플로우 라우팅 프로토콜

Country Status (6)

Country Link
US (1) US20140025804A1 (ko)
EP (1) EP2697957A1 (ko)
KR (1) KR20130136530A (ko)
CN (1) CN103460676A (ko)
FR (1) FR2973976B1 (ko)
WO (1) WO2012139819A1 (ko)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014022776A1 (en) 2012-08-03 2014-02-06 Intel Corporation Method and system for enabling device-to-device communication
US9526022B2 (en) * 2012-08-03 2016-12-20 Intel Corporation Establishing operating system and application-based routing policies in multi-mode user equipment
WO2014022797A1 (en) 2012-08-03 2014-02-06 Intel Corporation Device trigger recall/replace feature for 3gpp/m2m systems
US9036603B2 (en) 2012-08-03 2015-05-19 Intel Corporation Network assistance for device-to-device discovery
US9191828B2 (en) 2012-08-03 2015-11-17 Intel Corporation High efficiency distributed device-to-device (D2D) channel access
US8913518B2 (en) 2012-08-03 2014-12-16 Intel Corporation Enhanced node B, user equipment and methods for discontinuous reception in inter-ENB carrier aggregation
WO2015108458A1 (en) * 2014-01-20 2015-07-23 Telefonaktiebolaget L M Ericsson (Publ) Method nodes and computer program for enabling of data traffic separation
US10887243B2 (en) * 2015-12-27 2021-01-05 T-Mobile Usa, Inc. Aggregating multiple bandwidth sources

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100438513C (zh) * 2005-06-07 2008-11-26 华为技术有限公司 实现路由控制的系统和方法
US8539053B2 (en) * 2009-02-27 2013-09-17 Futurewei Technologies, Inc. Apparatus and method for dynamic host configuration protocol version 6 extensions for configuring hosts with multiple interfaces
CN101938526A (zh) * 2009-06-30 2011-01-05 中兴通讯股份有限公司 路由策略的获取方法、终端及服务器

Also Published As

Publication number Publication date
FR2973976A1 (fr) 2012-10-12
EP2697957A1 (en) 2014-02-19
WO2012139819A1 (en) 2012-10-18
CN103460676A (zh) 2013-12-18
FR2973976B1 (fr) 2013-08-30
US20140025804A1 (en) 2014-01-23

Similar Documents

Publication Publication Date Title
CN114930902B (zh) 用于在5G网络中启用传输服务质量(QoS)的方法、系统和计算机可读介质
KR20130136530A (ko) 원격 서버에 질의하는 것에 의한 플로우 라우팅 프로토콜
US20180191600A1 (en) Redirection of service or device discovery messages in software-defined networks
US9553770B2 (en) Method for controlling software defined network and apparatus for the same
EP3021534B1 (en) A network controller and a computer implemented method for automatically define forwarding rules to configure a computer networking device
US10659430B2 (en) Systems and methods for dynamic network address modification related applications
EP3293935B1 (en) Software defined network-based data processing method, and system
US8543674B2 (en) Configuration of routers for DHCP service requests
US20170237601A1 (en) Network Management
US20020138596A1 (en) Method to proxy IP services
CN106133714B (zh) 基于主机名选择网络服务
US10749733B2 (en) Apparatus and method for controlling network device based on network service in communication system
US11785095B2 (en) Method for routing data of a session initialized between a terminal and a server
CN113542452B (zh) 基于算法映射的实时IPv4-IPv6溯源方法及系统
US10827345B1 (en) Methods and systems for LoRaWAN traffic routing and control
WO2018164961A1 (en) Method and apparatus for configuring an administrative domain
Hoogendoorn Nsx-t Nat, Dhcp, and Dns Services
JP2008206081A (ja) マルチホーミング通信システムに用いられるデータ中継装置およびデータ中継方法
Enghardt et al. TAPS Working Group A. Brunstrom, Ed. Internet-Draft Karlstad University Intended status: Informational T. Pauly, Ed. Expires: 14 January 2021 Apple Inc.
Enghardt et al. TAPS Working Group A. Brunstrom, Ed. Internet-Draft Karlstad University Intended status: Informational T. Pauly, Ed. Expires: 10 September 2020 Apple Inc.
Enghardt et al. TAPS Working Group A. Brunstrom, Ed. Internet-Draft Karlstad University Intended status: Informational T. Pauly, Ed. Expires: May 7, 2020 Apple Inc.
Enghardt et al. TAPS Working Group A. Brunstrom, Ed. Internet-Draft Karlstad University Intended status: Informational T. Pauly, Ed. Expires: 6 May 2021 Apple Inc.
Enghardt et al. TAPS Working Group A. Brunstrom, Ed. Internet-Draft Karlstad University Intended status: Informational T. Pauly, Ed. Expires: January 9, 2020 Apple Inc.

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E601 Decision to refuse application