KR20130125804A

KR20130125804A - Traceroute_delay 진단 커맨드

Info

Publication number: KR20130125804A
Application number: KR1020137020955A
Authority: KR
Inventors: 팔렉 미첼 르; 딘 타이 뷔
Original assignee: 알까뗄 루슨트
Priority date: 2011-01-12
Filing date: 2012-01-03
Publication date: 2013-11-19
Also published as: EP2477357B1; US20140043992A1; KR101459252B1; EP2477357A1; JP2014506069A; CN103563307B; WO2012095335A1; US9509582B2; JP5646090B2; CN103563307A

Abstract

네트워크 경로 내에 포함된 적어도 하나의 네트워크 노드에 프로브 메시지의 상주 시간을 측정하기 위한 방법에 관한 것으로, 상기 프로브 메시지에는 Time-To-Live 값이 제공되고, 상기 방법은: 프로브 메시지의 수신 타임스탬프를 등록하는 단계; 수신 타임스탬프를 수신된 프로브 메시지 내의 전용 필드에 기록하는 단계; 프로브 메시지의 Time-To-Live 값을 체크하는 단계; Time-To-Live 값이 널(null)이 아니면, Time-To-Live 값을 1만큼 감소시키는 단계; Time-To-Live 값이 1이면, 프로브 메시지의 전송 타임스탬프를 등록하는 단계; 등록된 전송 타임스탬프에서 등록된 수신 타임스탬프를 차감함으로써 네트워크 노드 내의 프로브 메시지 상주 시간을 계산하는 단계; 계산된 상주 시간을 프로브 메시지 내의 필드에 기록하는 단계; 프로브 메시지에 대한 후속 동작에 의해 상주 시간이 중복하여 기록되는 것을 방지하기 위해 수신된 프로브 메시지 내의 플래그의 값을 변경하는 단계를 포함한다.

Description

TRACEROUTE_DELAY 진단 커맨드{TRACEROUTE_DELAY DIAGNOSTIC COMMAND}

본 발명은 일반적으로 네트워크 지연/레이턴시 관리의 기술 분야에 관한 것이다.

네트워크에 도입되는 지연은 이들이 VoIP, 쌍방향 네트워크 게이밍(interactive network gaming)과 같은 실시간 애플리케이션부터 시간적으로 중요한 금융 애플리케이션 및 위치결정 시스템까지 범위의 몇몇 광역 네트워크 애플리케이션에 직접적으로 영향을 미치기 때문에 가장 중요한 네트워크 성능 메트릭 중 하나이다.

따라서, 네트워크 내의 데이터 전송 지연의 성능을 모니터링하기 위해서는 이들 지연이 어떻게 그리고 어디서 도입되는지를 상세하게 이해해야 한다.

전통적인 TDM 기술 내에서, 네트워크 지연은 TDM 스위치들 간의 결정적 천이 시간에 의해(예를 들면, 시스템 클록 천이의 수와 관련하여) 예측가능하다. 그러나, 대역폭에 있어서의 거대한 증가 요구에 따라, TDM은 점차 패킷 스위치 네트워크(Packet Switch Network; PSN)로 대체되었으며, 이 PSN에서, 패킷 지연 변동(패킷 큐잉에 의해 기본적으로 도입되는 랜덤 프로세스)으로도 불리는 패킷 지터는 (이제부터 네트워크 노드 상주 시간으로 불리는) 네트워크 노드 내의 패킷 상주 시간을 예측 불가능하게 한다.

따라서, PNS 네트워크 오퍼레이터는, SLA(Service Level Agreement)를 중요시하고 네트워크 지연/레이턴시와 관련하여 SLA 위반을 정정하는 것을 목표로 하는 적절한 행동(예를 들면, 네트워크 재설계/재구성)을 취할 수 있게 하기 위해 네트워크 지연 또는 네트워크 레이턴시를 모니터링하기 위한 더 많은 도구를 필요로 한다.

이들 문제를 해결하기 위해, 네트워크 오퍼레이터는, 일반적으로, 다음과 같은 다양한 엔드-투-엔트(end-to-end) 시간-지연 측정 도구에 의존한다:

- 소스로부터 IP 네트워크 내의 목적지 호스트로의 엔드-투-엔드 라운드-트립 지연의 측정을 가능하게 하는 인터넷 제어 메시지 프로토콜(ICMPv4-RFC 792 및 ICMPv6-RFC 4443)에 정의된 PING 커맨드;

- RFC 2679에 의해 설명된 단방향 지연 측정 방법. 이 방법은 네트워크 지연/레이턴시 값, 요구되는 측정 정확도 및 양 단부에서의 클록 정확도에 의존하여 시간 동기화를 요구할 수 있다;

- 소스로부터 목적지 호스트로의 네트워크 경로를 따라 각각의 네트워크 노드(즉, 각각의 네트워크층 디바이스)의 어드레스를 결정할 수 있는 트레이스라우트(traceroute)(또는 트레서트(tracert)). 트레이스라우트는 또한 소스로부터 네트워크 경로 내의 각각의 트래버싱된 노드까지 엔드-투-엔드 지연을 각각 리턴한다.

그러나, 이들 도구는 네트워크 노드 상주 시간(또는 레이턴시)에 대한 어떠한 정밀도도 없이 전체적인 엔드-투-엔드 지연만을 리턴한다. 즉, 이들 도구에 의한 리턴된 지연 값은 어떠한 정밀도도 없이 네트워크 노드 상주 시간을 이미 포함하는 단일 유니터리(unitary) 컴포넌트로서 고려된다.

네트워크에 도입된 지연은 다음과 같이 광범위하게 분할될 수 있다:

- 네트워크 노드 상주 시간, 특히, 다음을 포함한다.

ㆍ 패킷을 처리하고(처리 지연) 그것을 (재)전송하기 위해 네트워크 노드에 필요한 시간. 처리 지연은 각각의 노드에서 이용가능한(즉, 이용가능한 하드웨어) 계산 전력 및 카드 드라이버(또는 인터페이스 카드 로직)의, 프로토콜 스택 복잡도의 함수이다.

ㆍ 큐잉 지연, 즉, 처리 및/또는 전송 전에 네트워크 노드의 버퍼 내에서의 패킷의 총 대기 시간 - 이 시간은 네트워크 노드의 스위칭(또는 하위 레이어 스위치)의 세부 사항에 의존할 수 있음 -

- 전송 지연: (제1 비트부터 최종 비트까지) 전체 비트 또는 보다 기본적으로 제1 네트워크 노드의 출력 포트로부터 제2 네트워크 노드의 입력 포트로의 단일 비트를 전송하는데 필요한 시간.

따라서, 컴포넌트에 대한 어떠한 세부 사항도 주어지지 않으면서 단일 값으로 전체의 엔드-투-엔드 지연을 리턴함으로써, 종래의 엔드-투-엔드 지연 도구는 오퍼레이터가, 이슈를 초과하는 레이턴시 예산을 해결하기 위해 정정 액션이 적용되어야 곳에 네트워크 세그먼트(들) 또는 네트워크 노드(들)를 구성할 수 없다.

종래 기술의 또 다른 문제점은, 기존 네트워크 진단 도구는 총 전송 레이턴시 중 어느 정도 비율이 네트워크 노드 상주 시간에 기인하는지 결정하는 것을 승인하지 못한다.

본 발명의 하나의 목적은 종래 기술의 전술한 문제점 및 다른 문제점을 해결하는 것이다.

본 발명의 다른 목적은 네트워크 경로 내의 어디에 현저한 지연이 도입되는 지를 정확하게 식별하는 것이다.

본 발명의 또 다른 목적은 네트워크에 도입되는 지연의 미세한(fine-grained) 구성을 제공하는 것이다.

본 발명의 또 다른 목적은 노드마다의 레이턴시를 결정하는 것을 승인하는 방법을 제안하는 것이다.

본 발명의 또 다른 목적은 프로브 메시지의 콘텐츠를 제어함으로써, 이 패킷이 수행하는 엔드-투-엔드 지연의 미세 픽처를 제공하는 커맨드를 제공하는 것이다.

본 발명의 또 다른 목적은 엔드-투-엔드 지연을, 소스로부터 IP 네트워크 내의 목적지로의 경로를 따라 노드 상주 시간들을 구별하는 컴포넌트로 분할하는 것이다.

본 발명의 또 다른 목적은 오퍼레이터가 네트워크 레이턴시와 관련하여 SLA 위배 이슈(인정(committed) 서비스의 품질은 고려되지 않음)를 빠르고 정확하게 전달하도록 하는 것이다.

본 발명의 또 다른 목적은 인터넷 애플리케이션에서 중요한 지연의 소스를 정확하게 식별하도록 하는 진단 커맨드를 제공하는 것이다.

본 발명의 또 다른 목적은 최대의 레이턴스를 도입하고 지연 저하를 담당하는 현저한 네트워크 홉(hop)을 노출시키는(uncover) 것이다.

본 발명의 목적, 이점 및 다른 특징은 다음의 설명 및 청구범위로부터 보다 자명해 질 것이다. 다음의 바람직한 실시예의 비제한적인 설명은 첨부 도면을 참조하여 단지 예시의 목적으로 제공된다.
도 1은 종래 기술에 따른 프로브 헤더의 포맷을 도시하는 블록도이다.
도 2는 제1 실시예에 따른 프로브 헤더의 포맷을 도시하는 블록도이다.
도 3은 종래의 진단 커맨드 트레이스라우트()의 실시예를 도시하는 블록도이다.
도 4는 진단 커맨드의 기능적 실시예를 도시하는 블록도이다.
도 5는 제2 실시예에 따른 프로브 헤더의 포맷을 도시하는 블록도이다.

본 발명은 전술한 하나 이상의 문제의 영향을 해결하는 것이다. 다음은 본 발명의 몇몇 양상의 기본적인 이해를 제공하기 위해 본 발명의 간략화된 개요를 제공한다. 이 개요는 본 발명의 모든 개관이 아니다. 본 발명의 중요한 요소를 식별하거나 또는 본 발명의 범위를 묘사하고자 의도된 것도 아니다. 유일한 목적은 후술되는 보다 상세한 설명에 대한 서두로서 몇몇 개념을 간략화된 형태로 제시하는 것이다.

본 발명은 네트워크 경로 내에 포함된 적어도 하나의 네트워크 노드에 프로브 메시지의 상주 시간을 측정하기 위한 방법에 관한 것으로, 상기 프로브 메시지에는 Time-To-Live 값이 제공되고, 상기 방법은:

- 프로브 메시지의 수신 타임스탬프를 등록하는 단계;

- 수신 타임스탬프를 수신된 프로브 메시지 내의 전용 필드에 기록하는 단계;

- 프로브 메시지의 Time-To-Live 값을 체크하는 단계;

- Time-To-Live 값이 널(null)이 아니면, Time-To-Live 값을 1만큼 감소시키는 단계;

- Time-To-Live 값이 1이면,

ㆍ 프로브 메시지의 전송 타임스탬프를 등록하는 단계;

ㆍ 등록된 전송 타임스탬프에서 등록된 수신 타임스탬프를 차감함으로써 네트워크 노드 내의 프로브 메시지 상주 시간을 계산하는 단계;

ㆍ 계산된 상주 시간을 프로브 메시지 내의 필드에 기록하는 단계;

ㆍ 프로브 메시지에 대한 후속 동작에 의해 상주 시간이 중복 기록되는 것을 방지하기 위해 수신된 프로브 메시지 내의 플래그의 값을 변경하는 단계를 포함한다.

광의의 양상에 따라, 전술한 상기 방법은,

- Time-To-Live 값이 널이면, 감소된 후,

ㆍ 계산된 상주 시간의 복사본, 관련 플래그 값 및 프로브 메시지로부터의 프로브 메시지 식별자를 갖는 프로브 응답 메시지를 생성하는 단계;

ㆍ 생성된 프로브 응답 메시지를 프로브 메시지의 발신자 쪽으로 전송하는 단계

를 더 포함한다.

광의의 양상에 따라, 프로브 메시지는 수정된 ICMP(Internet Control Message Protocol) 메시지이다.

또 다른 광의의 양상에 따라, 프로브 메시지는 MPLS-TP/MPLS OAM 메시지 또는 Ethernet OAM 메시지와 같은 수정된 OAM(Operation Administration Maintenance) 메시지이다.

이롭게도, 네트워크 노드 내의 프로브 메시지의 계산된 상주 시간은, 프로브 메시지 처리(즉, 코딩/디코딩)를 담당하는 주 프로토콜 레이어/스택 내의 상주 시간과 동일하다. 따라서, 상이한 프로토콜 레이어에서 프로브 메시지를 사용함으로써, 각각의 노드 지연 예산에 대한 상이한 프로토콜 레이어의 영향을 분석할 수 있다.

본 발명은 또한 네트워크 노드에 관한 것으로, 상기 네트워크 노드는,

- 프로브 메시지의 수신 타임스탬프를 등록하기 위한 수단;

- 수신 타임스탬프를 수신 프로브 메시지 내의 전용 필드 내에 기록하기 위한 수단;

- 프로브 메시지의 Time-To-Live의 값을 체크하기 위한 수단;

- 프로브 메시지의 전송 타임스탬프을 등록하기 위한 수단;

- 등록된 전송 타임스탬프와 기록된 수신 타임스탬프 간의 차이인 프로브 메시지 상주 시간을 계산하고, 프로브 메시지 내의 필드에 기록하기 위한 수단;

- 계산된 상주 시간 값이 다른 노드들 또는 프로브 메시지의 현재 노드 자체의 후속 동작에 의해 중복하여 기록되는 것을 방지하기 위해 프로브 메시지 내의 플래그 값을 변경하기 위한 수단;

- 프로브 메시지의 Time-To-Live의 값을 감소시키고 비교하기 위한 수단;

- 프로브 메시지, 특히 계산된 상주 시간으로부터 상이한 정보가 복사된 프로브 응답 메시지를 생성하기 위한 수단을 포함한다.

본 발명은 또한 전술한 방법을 수행하도록 적응된 컴퓨터 프로그램 제품에 관한 것이다.

본 발명은 다양한 수정 및 대체 형태로 인지될 수 있지만, 본 발명의 특정 실시예는 도면에 예로서 도시되었다. 그러나, 특정 실시예의 설명은 본 발명을 개시된 특정 형태로 제한하고자 의도하는 것이 아니다.

물론, 임의의 그러한 실제 실시예의 전개시에, 구현-특정 결정은 시스템 관련 및 비지니스 관련 제한과의 부합과 같은 개발자의 특정 목표를 달성하도록 이루어져야 한다는 것이 이해될 것이다. 그러한 개발 노력은 시간을 소비하게 되지만, 그럼에도 불구하고 본 개시의 이점을 갖는 분야의 당업자에게는 일반적인 이해일 수 있다는 것이 이해될 것이다.

이하에 traceroute_delay()로 지정된 진단 커맨드가 제공된다. 이러한 지정은 전통적인 traceroute() 커맨드(예를 들면, RFC1393) 및 지연 측정 이슈를 어느 정도 결합하여 단지 명명의 목적으로 부여된 것이다. 분명하게도, 임의의 다른 이름이 부여될 수 있다.

프로브 메시지 헤더를 제어함으로써, traceroute_delay() 커맨드는, 트래버싱된 노드 어드레스들에 부가하여, 트래버싱된 노드 상주 시간 및 결과적으로 트래버싱된 링크 전파 지연을 수집한다.

일 실시예에서, 프로브는 수정된 ICMP 메시지이다. 사실, traceroute_delay() 커맨드는 ICMP 타임스탬프 및 ICMP 타임스탬프 응답 메시지(RFC 972)의 몇몇 필드를 사용하며, 이들은 (이들 기존 필드에 새로운 의미을 제공하는) 예상되는 것이 상이하다.

도 1 및 도 2를 참조하면, 종래의 ICMP 타임스탬프 또는 타임스탬프 응답 메시지(RFC 972)의 필드 "Originate Timestamp", "Receive Timestamp", 및 "Transmit Timestamp"(도 1)는 각각, traceroute_delay() 커맨드에 따라, "Outbound Resident Time", "Receive Timestamp" 및 "Return Resident time" 필드(도 2)로 대체된다. 더욱이, 플래그 "L"은 "Outbound Resident Time" 및 "Return Resident Time" 필드 중 각각과 연관된다.

따라서, 프로브 헤더는, traceroute_delay() 커맨드에 따라,

- 필드 "Type", "Code", "Checksum", "Identifier", 및 "sequence number"와 같은 Timestamp Reply 메시지 및 ICMP Timestamp를 갖는 공통 필드(도 1 및 도 2). 이들 필드는 인식된 기능(즉, 데이터 청크의 손실을 결정하기 위한 "Checksum" 필드, 또는 메시지를 식별하는 것을 승인하는 "Identifier" 필드와 같은 표준 해석)에 따라 사용된다;

- "Outbound Resident Time" 필드: 이 필드는 아웃바운드 방향에서 네트워크 노드의 패킷 상주 시간(마이크로초)이다;

- "Receive Timestamp" 필드: 이 필드는 각각의 트래버싱된 노드에서 패킷 수신 타임스탬프를 로그하기 위한 플레이스홀더이다. 이것은 노드가 전송 타임스탬프에서 이 타임스탬프를 차감함으로써 전송시 패킷 상주 시간을 계산하도록 할 수 있다;

- "Retrun Resident Time": 이 필드는 리턴 방향에서 라우터의 패킷 상주 시간(마이크로초)이다;

- "L" 비트: 각각의 필드(Outbound/Return Resident Time)를 고정(lock)하고 다른 노드 또는 현재 노드 자체에 의한 패킷의 후속 처리에 의해 중복 기록되는 것을 방지하기 위한 플래그를 포함한다.

수정된 ICMP 타임스탬프 또는 타임스탬프 응답 메시지의 사용은 단지 이들의 이미 표준화된 메시지보다 오히려 빠른 구현 및 배치를 유도하는 미사용 메시지를 이용하기 위한 목적이다.

대안으로, 전술한 프로브 포맷은 ICMP Timestamp 및/또는 Timestamp reply message에 대한 어떠한 고려 없이도 정의될 수 있다. 프로브 헤더는 "Outbound Resident Time", "Receive Timestamp", "Return Resident Time" 필드, 및 "Outbound Resident Time" 및 "Return Resident Time" 필드 중 각각의 필드와 연관된 보호 플래그 "L"을 포함하는 것으로 인식된다. 이들 필드는 전술한 작업용으로 프로그래밍된다.

traceroute_delay() 커맨드는 다음의 신택스(syntax)를 갖는다:

traceroute_delay(destination address, [QoS, mode])

여기서,

- "destination address"는 목적지 네트워크 노드의 어드레스이다;

- "QoS"는 발신 포인트에서 traceroute_delay() 커맨드를 전송하는 관련 프로토콜 프로브 메시지를 태그 하기 위한 Quality of Service(QoS) 또는 Class of Service(CoS) 값을 특정한다. 오퍼레이터에 의해 특정된 값이 없거나 디폴트로서, "QoS" 값은 "Best Effort" 값으로 설정된다;

- "mode"는 커맨드의 동작 모드를 지시하는 것으로, 단방향(즉, 값 0) 또는 양방향(즉, 값 1)을 의미한다. 오퍼레이터에 의해 특정된 값이 없거나 디폴트로서, 값은 1로 설정된다.

"destination address"의 포맷은 traceroute_delay() 커맨드를 전송하는데 사용되는 프로토콜 및 기술에 의존한다. 예를 들면,

- 이 커맨드가 ICMP의 확장(RFC 4884 & 5837)을 통해 전송된다면, IP 어드레스(또는 호스트네임); 또는

- 이 커맨드가 비-IP 네트워크에서 MPLS-TP(Multi-protocol Label Switching Transport Profile) OAM 프로토콜(Operation And Maintenance, 또한 Operation Administration and Maintenace로도 알려짐)(RFC 5860)을 통해 전송된다면, NSAP(Network Service Access Point) 어드레스일 수 있다.

입력 "QoS"는:

- ICMP와 같은 IP 상의 프로토콜이 사용된다면, IP 헤더의 Differenciated Services Code Point(DSCP) 필드에 대해;

- MPLS OAM 또는 Pseudo-wire(PW) OAM이 사용된다면, 일반적인 Multi-protocol Label Switching(MPLS) 라벨에서의 Experimental use(EXP)에 대한 3-비트 유보 필드에 대해; 또는

- 상이한 traceroute_delay() 메시지를 전송하는데 Ethernet OAM이 사용된다면, IEEE802.1p에 의해 참조되는 3-비트 Priority Code Point(PCP)에 대해 설정될 값이다.

사실, 데이터 패킷 지연은 종종, 각각의 트래버싱된 노드에서 그리고 구성된 관련 스케줄링에 적용되는 차분 서비스 처리에 의해, (발신/출발 포인트에서) 할당된 "QoS"에 의존한다.

"mode" 입력과 관련하여, 패킷 지터 크기는 각각의 통신 방향(아웃바운드 방향 및 리턴 방향) 각각에서 상이하고, 패킷 상주 시간은 종종 각각의 방향에 대해 상이하다. 따라서, 두 개의 모드, 즉, 단방향 모드 및 양방향 모드가 제공된다. "Identifier" 필드의 최상위 비트는 단방향(값 0)과 라운드-트립 지연(값 1) 측정 모드 사이를 분리할 수 있다.

보다 일반적으로, traceroute_delay() 커맨드의 호출(invocation)을 정의하는데 다음과 같은 다른 입력 파라미터들 또한 고려될 수 있다:

- (디폴트로서) UDP, ICMP 또는 TCP 같은 프로브 패킷 프로토콜을 언급하는 "protocol";

- 네트워크 노드 당 프로브 패킷의 수를 지시하는 "p".

traceroute_delay() 커맨드의 거동을 소개하기 위해, 전통적인 트레이스라우트 커맨드의 기본 알고리즘의 간략한 리마인더가 도 3에 도시되어 있다.

ICMPv4에 대해, 전통적인 traceroute() 커맨드는 노드(1에서 n까지)를 링크하는 네트워크 경로를 따라 각각의 노드(2에서 n까지)가 ICMP 에러 메시지를 리턴하게 함으로써 동작한다. 프로빙(probing)은 일련의 라운드-트립(11-13)에서 소스로부터 목적지 i(i=2,..., n)를 향해 이동하면서 홉-바이-홉(hop-by-hop)이 행해진다. 일 단부에서 시작하는 Time-To-Live 또는 홉 카운트는 목적지 노드 n에 도달할 때까지 또는 또 다른 정지 조건이 적용될 때까지 각각의 라운드-트립(11-13) 후에 증가된다.

사실, 전통적인 traceroute()는 TTL=1(Time-To-Live)을 이용하여 자신의 제1 패킷 그룹을 전송한다. 따라서, 경로(노드 2)를 따르는 제1 라우터는 패킷들(제로까지 감소된 TTL)을 소거할 것이고 ICMP "TTL Exceed" 에러 메시지를 리턴한다(라운드-트립(11)). 따라서, traceroute()는 제1 라우터 (노드(2)) 어드레스를 등록할 수 있다. 다음에, 패킷은 TTL=2를 이용하여 전송될 수 있고(라운드-트립(12), 다음에 TTL=3를 이용하여 전송될 수 있으며(라운드-트립(13)), 경로를 따르는 각각의 라우터가 에러를 리턴하게 하고, 그것을 (소스 라우터 또는 호스트에 위치된) traceroute() 커맨드에 대해 식별한다. 결과적으로 최종 목적지(노드(n))에 도달하거나, 최대의 TTL 값(디폴트는 30임)에 도달하고 traceroute()는 종료된다. 최종 목적지에서, 상이한 에러가 리턴된다.

몇몇 구현예는 UDP 데이터그램을 아무것도 들리지 않는 몇몇의 랜덤 고수(high-numbered) 포트로 전송합으로써 동작하고, 몇몇의 다른 구현예는 ICMP 에코 패킷을 사용한다.

이제, 종래의 traceroute() 커맨드와 유사한 도 4를 참조하면, traceroute_delay()는 TTL=1(라운드-트립(11))을 이용하여, 다음에 TTL=2(라운드-트립(12)), TTL=3(라운드-트립(13))을 이용하여 연속적으로 ICMP 타임스탬프 메시지를 목적지 게이트웨이(노드(n))까지 전송한다. 노드(n)을 향하는 이 방향을 아웃바운드 방향이라고 지칭한다. 그 반대 방향은 리턴 방향으로 지칭된다.

아웃바운드 방향에 대해, 각각의 트래버싱된 노드 i(i=2, ..., n)는 다음의 동작을 실현한다:

- (도 4의 단계 21):

ㆍ 담당 프로토콜이 패킷 존재를 검출하자마자 타임스탬프 패킷 수신 시간을 등록하고 (예를 들면, 하드웨어 타임스탬핑을 사용하는 입력 포트에서)(이것은 이 패킷이 네트워크 노드 내의 관련 프로토콜 스택(예를 들면, IP 프로토콜, 이더넷 프로토콜 등)에 의해 수신되는 타임 인스턴트(time instant)를 마킹함), 타임스탬프 값을 패킷 "Receive Timestamp" 필드에 기록한다(단계 21);

ㆍ TTL을 1씩 감소시킨다;

- (도 4의 단계 22), TTL=1이면, 패킷 전송 프로세스에서(예를 들면, 출력 포트에서),

ㆍ 패킷 전송 타임스탬프를 등록하고, 이 패킷이 전송을 위한 관련 프로토콜을 떠나는 타임 인스턴트를 마킹한다(예를 들면, IP 스택에 대해, 이것은 IP 스택이 ICMP 패킷을 전송을 위한 이더넷 레이어와 같은 전송 레이어로 조정할 때의 인스턴트이다);

ㆍ 노드 i에서 측정된 패킷의 전송 타임스탬프와 수신 타임스탬프 간의 차로서 노드 i에서의 패킷 상주 시간을 계산한다;

ㆍ 그와 같이 계산된 상주 시간 값을 패킷 "Outbound Resident Time" 필드에 기록한다;

ㆍ 후속 동작에 의해 중복 기록되는 것을 방지하기 위해 이 필드의 L-비트를 1로 설정한다(L-비트가 이미 설정되어 있다면, 에러가 있는 경우이고; 이전 노드가 TTL 값을 감소시키는 것을 망각하였거나, 에러에 의해 L-비트를 설정한 것이고, 다음에, 액션은 패킷 쪽으로 행해지는 것이 아니라 "Timestamp Reply" 메시지를 다시 전송하여 "Outbound Resident Time" 필드를 0으로 설정하고 관련 L-비트를 1로 설정한다);

그 외에, 목적지에 도달하거나 또는 TTL=0이면(도 4의 단계 31),

ㆍ "Timestamp" 메시지로부터 복제/복사되는 관련 L비트 및 "Outbound Resident Time" 필드를 이용하여 생성되는 "Timestamp Reply"를 생성한다. 이것은 또한 "Identifier" 필드에 대한 경우이기도 하다. "Timestamp Reply" 메시지는 다시 "Timestamp message"의 발신자에게로 전송된다;

ㆍ TTL=0이고 목적지에 도달하지 않으면, ICMP "TTL Exceed" 에러 메시지를 발신자에게 다시 전송한다.

리턴 방향에 대해, 각각의 노드는 다음의 동작을 실현한다:

- (도 4의 단계 23):

ㆍ (예를 들면, 입력 포트에서) 패킷을 검출하자마자 타임스탬프 응답 패킷 수신 타임스탬프를 등록한다; 그리고

ㆍ 수신 타임스탬프 값을 패킷 "Receive Timestamp" 필드에 기록한다;

(도 4의 단계 24), "Identifier" 필드의 최상위 비트가 설정되고(양방향 모드, 즉, 값 1), L비트와 연관된 "Retrurn Resident Time"이 설정되지 않으면, 출력 포트에서,

ㆍ 수신 타임스탬프에 기초하여 패킷 상주 시간을 계산한다: 전송 타임스탬프와 수신 타임스탬프 간의 차; 및

ㆍ 그와 같이 계산된 값을 패킷 "Return Resident Time" 필드에 기록한다;

ㆍ 후속 동작에 의해 "Return Resident time" 필드에 중복 기록되는 것을 방지하기 위해 관련 L비트를 1로 설정한다.

사기 알고리즘 애플리케이션의, TTL=2를 갖는 설명의 예가 도 4에 도시되어 있다(라운드-트립 12). 이 예에서,

- 노드 2는 입력 포트로부터 패킷을 검출하자마자 수신 프로브의 필드 "Receive Timestamp field"에 수신 타임스탬프 값을 기록한다(도 4의 단계 21);

- 노드 2는 TTL를 1만큼 감소시킨다. TTL=1이면, 노드 2는 상주 시간을 계산하고 이것은 "Outbound Resident Timestamp"에 기록하며, 이 필드에 중복하여 기록되는 것을 방비하기 위해 L-비트는 1로 설정한다(도 4의 단계 22);

- 노드 3은 TTL을 0으로 감소시킨다. "Outbound Resident Timestamp"를 소거하기 전에, 노드 3은 적절한 필드를 새롭게 생성된 타임스탬프 응답 메시지 내의 관련 필드에 복사한다. 노드 3은 후자의 메시지를 다시 소스 라우터 또는 소스 호스트에 전송한다(도 4의 단계 31);

- 노드 2는 패킷 수신 타임스탬프를 등록하고 "Receive Timestamp" 필드에 기록한다;

- "Identifier" 필드의 최상위 비트가 양방향 모드로 설정되면, 노드 2는, 출력 포트에서, 리턴 상주 시간을 계산하고, 타임스탬프 응답 메시지의 필드 "Return Resident Time"을 업데이트한다. 다음에, 이 후자의 필드에 연관된 L-비트는 중복하여 기록되는 것을 방지하기 위해 1로 설정된다(도 4의 단계 24).

보다 일반적으로, 각각의 라운드-트립(11-13) 내에서 - 여기서 TTL=i(i=1, ..., n-1), 노드 i에서, 단방향 및/또는 양방향 모드에서 상주 시간이 측정된 다음 프로브 메시지 헤더에 저장된다. 따라서, 노드마다의 상이한 단방향 상주 시간이 오퍼레이터를 위해 요약 테이블에 표시될 수 있다.

이를 위해, 네트워크 노드 i(i=2, ..., n)는,

- 프로브 패킷을 검출하자마자(즉, 관려된 프로토콜 스택에 의해 검출됨에 따라) 입력 포트로부터 프로브 패킷의 수신 타임스탬프를 등록하기 위한 수단;

- 수신 타임스탬프를 프로브 패킷 내의 필드에 기록하기 위한 수단;

프로브 패킷의 Time-To-Live의 값을 체크하고 계산하기 위한 수단;

- 프로브 패킷의 전송 타임스탬프를 등록하기 위한 수단(즉, 패킷이 전송을 위해 관련 프로토콜 스택을 떠나는 인스턴트에서);

- 등록된 전송 타임스탬프와 수신 타임스탬프 간의 차이인 패킷 단방향 상주 시간을 계산하고 프로브 패킷 내의 필드 내에 기록하기 위한 수단;

- (다른 네트워크 노드 또는 노드 자신에 의해) 프로브 메시지에 대한 후속 동작에 의해 계산된 상주 시간이 중복하여 기록되는 것을 방지하기 위해 프로브 패킷 내의 플래그의 값을 변경하기 위한 수단;

- 프로브 패킷의 Time-To-Live의 값을 감소시키고 비교하기 위한 수단을 포함한다.

노드가 1만큼 감소된 후 1보다 엄격하게 큰 TTL을 갖는 프로브 패킷을 수신하면, 프로브 패킷은 상주 시간 측정 단계없이 전달된다는 것을 유의해야 한다.

MPLS-TP OAM에 대한 또 다른 실시예는, 전술한 알고리즘에 더하여, IETF 문서 "Operating MPLS Transport Profile LSP in Loopback Mode"(2010년 3월)를 이용한다.

상이한 OAM Loopback은 원격/목적지 MEP에 도달할 때까지 TTL을 1부터 증가시키면서 전송/소스 MEP(Maintenance End Point)에 의해 수행되어야 한다.

MPLS-TP OAM-embedded traceroute_delay 메시지는 이러한 목적을 위해 정의되어 있다. 이 메시지의 포맷(MPLS-TP traceroute_delay)가 도 4에 도시되어 있으며, 여기서,

- "Outbound/Return"은 메시지 방향을 특정한다: Outbound(값 0x00 - 이전 "Timestamp" 메시지와 동일) 방향 또는 리턴 방향(값 0x01 - 이전 "Timestamp Reply" 메시지와 동일);

- "L-비트"는 ICMP 실시예에서 이전에 설명된 바와 동일한 의미를 갖는다;

- "Outbound Resident Time"은 ICMP 실시예에서 이전에 설명된 바와 동일한 의미를 갖는다;

- "Receive Timestamp"는 ICMP 실시예에서 이전에 설명된 바와 동일한 목적을 갖는다;

- "Return Resident Time"은 ICMP 실시예에서 이전에 설명된 바와 동일한 의미를 갖는다;

- "Originator Transmit Timestamp"는 (발신자 로컬 클록에 따라) 소스/발신자에 의해 전송될 때 패킷의 타임스탬프를 지시한다;

- "One-way Receive Timestamp"는 (목적지 노드 로컬 클록에 따라) 목적지 노드에 의해 수신될 때 패킷의 타임스탬프를 지시한다.

마지막 두 개의 필드는 끝에서 끝가지의 단방향 지연(즉, "One-way Receive Timestamp" - "Originator Transmit Timestamp")을 계산하기 위한 traceroute_delay() 커맨드를 고려한다. 이것은 목적지 노드 클록이 측정 요구사항에 부합하는 정확도로 발신자 클록과 동기화된다고 가정한다.

"Originator Transmit Timestamp"는 발신자가 리턴 메시지의 수신시에 라운드-트립 지연을 계산하게 할 수 있다. 이것은 "Outbound" 메시지(이 메시지는 이전 실시예에서의 "Timestamp" 메시지와 동일)의 "Originator Transmit Timestamp" 필드가 "Return" 메시지(이 메시지는 이전 실시예에서의 "Timestamp Reply" 메시지와 동일)의 "Originator Transmit Timestamp" 필드에 복사된다.

이전 ICMP 실시예에서, 발신자는 "Originator Transmit Timestamp"가 없더라도 라운드-트립 지연을 측정할 수 있다는 것을 유의해야 한다. 예를 들면, 각각의 메시지 식별자(즉, "Identifier" 필드) 값에 대해 관련 전송 타임스탬프를 국부적으로(즉, 로컬 콘텍스트 메모리에서) 로그하고 동일 식별자를 갖는 "Timestamp Reply" 메시지의 수신 타임스탬프를 로그할 수 있다.

측정된 연속적인 라운드-트립 시간들은 traceroute_delay() 커맨드가 (링크 지연이 동기된다고 가정하여) 라운드-트립 시간으로부터 노드 상주 시간을 차감함으로써 총 링크 지연을 계산할 수 있게 한다는 것이 중요하다.

네트워크 노드 상주 시간은 다른 레이어들과는 독립적으로 각각의 프로토콜 레이어에서 모니터링된다. 예를 들면, IP/이더넷 네트워크에서:

- ICMP/IP 프로토콜 레이어는 입력되는 이더넷 MAC 인터페이스로부터 입력되는 패킷을 (IP 프로토콜 스택 뷰로부터) 검출할 수 있는 시점으로서 패킷 수신 시간(수신 타임스탬프)을 로그하고; 패킷을 출력되는 이더넷 MAC 인터페이스로 조정하는 시점으로서 패킷 전송 시간을 로그한다;

- 이더넷 OAM 레이어는 입력되는 물리적 인터페이스로부터 입력되는 패킷의 프레임 시작을 검출할 수 있는 시점으로서 패킷 수신 시간(수신 타임스탬프)을 로그하고; 출력되는 물리적 인터페이스로 패킷을 조정하는 시점으로서 패킷 전송 시간(전송 타임스탬프)을 로그한다.

따라서, 주어진 네트워크 노드에 대해, ICMP/IP 레이어에서 보고되는 평균 상주 시간은 이더넷 OAM 레이어에 의해 보고되는 것보다 더 작다. 후자(프로토콜 스택 내의 최하위 프로토콜)에 대해, 하드웨어 타임스탬핑이 구현될 수 있다. 이것은 주어진 노드 내에서, 네트워크 노드 레이턴시에 가장 영향을 미치는 프로토콜 레이어를 분석할 수 있다. 노드 내의 매 레이어마다에서 상주 시간 측정 방법은 구현이 특정적이고 본 발명의 범위 내에 있는 것은 아니다.

"Timestamp Reply" 메시지 IP 소스 어드레스는 traceroute_delay()에게, 아웃바운드 및 리턴 상주 시간 모두 측정되는 IP 어드레스를 제공하지만 아웃바운드 경로 상의 다음 노드의 IP 어드레스를 제공하는 것은 아니라는 것을 유의해야 한다. 노드 IP 어드레스를 얻기 위해, 커맨드는 이전 "Timestamp Reply" 메시지를 참조해야 한다.

traceroute_delay()는 다음과 같은 프로브 메시지를 전송하기 위한 상이한 방법을 사용할 수 있다:

- 패킷별로(packet-by-packet): 종래의 트레이스라우트로서, 즉, 프로브를 전송하고, 답 또는 타임아웃을 대기하며, 다음의 프로브를 전송한다;

- 노드별로(node-by-node): (오퍼레이터에 의해 입력되거나 디폴트 값으로 부여되는) 프로브들 간의 구성가능한 지연을 갖는 주어진 노드에 대해 하나보다 많은 프로브를 전송하고, 답 또는 타임아웃을 대기한 다음, 다음 노드에 대해 동일한 절차를 반복한다.

커맨드는 진단 목적으로 요구에 의해 실행될 수 있지만, 고객이 이슈를 발견하기 전에 빠르게 반응하기 위해 사전에 정규적인 시간 간격으로 자동으로 실행될 수 있다는 것이 중요하다.

traceroute_delay() 커맨드는 오퍼레이팅 시스템에 또한 포함될 수 있거나, (NetTools)과 같은 네트워크 도구에 포함될 수 있다.

네트워크 노드 상주 시간 측정에 관한 것이기 때문에, 실제로 상주 시간이 몇 ms로 작기 때문에 노드 클록들을 동기화할 필요는 없다. 자유롭게 실행되는 전통적인 저비용 100ppm(part-per-million) 정확도의 클록(예를 들면, 이더넷 인터페이스 클록)은 10 ms의 상주 시간에 대해 1㎲(100x10^-6x10x10^-3)의 측정 에러가 발생한다(그리고 전형적인 10개 노드의 캐스케이스에 대해서는 10㎲ 이하의 최대 측정 에러가 발생한다).

이롭게도, 네트워크 경로 내의 노드 상주 시간의 알게 됨으로써, 수용가능한 지연 바운드를 제공하는데 실행하는 노드를 식별할 수 있게 된다. 더욱이, 도입된 지연들을 네트워크 링크 또는 노드들에게 결정적이고 정확하게 할당할 수 있다.

이롭게도, 전술한 방법은 단 대 단 시간 지연을 두 개의 컴포넌트, 즉, 네트워크 세그먼트(또는 링크) 상의 전송 지연 및 노드 상주 시간으로 분할할 수 있다. 따라서, traceroute_delay() 커맨드는 단 대 단 단방향(양방향) 지연이 SLA 임계치를 초과할 때 재작업/재엔지니어링될 네트워크 세그먼트(들) 또는 네트워크 노드(들)를 지시하게 할 수 있는 단 대 단 단방향(양방향) 지연의 상세한 뷰/할당을 제공한다.

Claims

네트워크 경로 내에 포함된 적어도 하나의 네트워크 노드에서 프로브 메시지의 상주 시간을 측정하기 위한 방법 - 상기 프로브 메시지에는 Time-To-Live 값이 제공됨 - 으로서,
상기 프로브 메시지의 수신 타임스탬프를 등록하는 단계와,
상기 수신 타임스탬프를 수신된 상기 프로브 메시지 내의 전용 필드에 기록하는 단계와,
상기 프로브 메시지의 Time-To-Live 값을 체크하는 단계와,
상기 Time-To-Live 값이 널(null)이 아니면, 상기 Time-To-Live 값을 1만큼 감소시키는 단계와,
상기 Time-To-Live 값이 1이면,
상기 프로브 메시지의 전송 타임스탬프를 등록하는 단계와,
상기 등록된 전송 타임스탬프에서 상기 등록된 수신 타임스탬프를 차감함으로써 상기 네트워크 노드 내의 상기 프로브 메시지의 상주 시간을 계산하는 단계와,
상기 계산된 상주 시간을 상기 프로브 메시지 내의 필드에 기록하는 단계와,
상기 프로브 메시지에 대한 후속 동작에 의해 상기 상주 시간이 중복하여 기록되는 것을 방지하기 위해 수신된 상기 프로브 메시지 내의 플래그의 값을 변경하는 단계를 포함하는
방법.
제 1 항에 있어서,
상기 방법은,
상기 Time-To-Live 값이 감소된 후, 상기 Time-To-Live 값이 널이면,
상기 프로브 메시지로부터의 상기 계산된 상주 시간, 관련 플래그 값 및 프로브 메시지 식별자의 복사본을 갖는 프로브 응답 메시지를 생성하는 단계와,
상기 생성된 프로브 응답 메시지를 상기 프로브 메시지의 발신자 쪽으로 다시 전송하는 단계를 더 포함하는
방법.
제 1 항 또는 제 2 항에 있어서,
상기 프로브 메시지는,
제 1 통신 방향에서 트래버싱된(traversed) 네트워크 노드 내의 상기 프로브 메시지의 상주 시간을 전달하기 위한 제 1 필드와,
네트워크 노드의 입력 포트로부터 상기 프로브 메시지의 수신 타임스탬프를 로그하기 위한 플레이스홀더(placeholder)와,
상기 프로브 메시지에 대한 임의의 후속 동작에 의해 상기 제 1 필드에 중복하여 기록되는 것을 방지하기 위한 제 1 플래그를 포함하는
방법.
제 3 항에 있어서,
상기 프로브 메시지는,
상기 제 1 통신 방향과는 반대인 제 2 통신 방향에서 트래버싱된 네트워크 노드 내의 상주 시간을 전달하기 위한 제 2 필드와,
상기 프로브 메시지에 대한 임의의 후속 동작에 의해 상기 제 2 필드에 중복하여 기록되는 것을 방지하기 위한 제 2 플래그를 더 포함하는
방법.
제 3 항 또는 제 4 항에 있어서,
상기 트래버싱 네트워크 노드에서의 통신 방향에 대한 정보는 상기 프로브 메시지 내에서 전달된 적어도 하나의 필드에 의해 지시되는
방법.
제 1 항 내지 제 5 항 중 어느 한 항에 있어서,
상기 프로브 메시지는 수정된 인터넷 제어 프로토콜(Internet Control Protocol) 메시지인
방법.
제 1 항 내지 제 5 항 중 어느 한 항에 있어서,
상기 프로브 메시지는 수정된 동작 관리 유지보수(Operation Adminstration Maintenance) 메시지인
방법.
네트워크 노드로서,
프로브 메시지의 수신 타임스탬프를 등록하기 위한 수단과,
상기 수신 타임스탬프를 수신된 상기 프로브 메시지 내의 전용 필드에 기록하기 위한 수단과,
상기 프로브 메시지의 Time-To-Live의 값을 체크하기 위한 수단과,
상기 프로브 메시지의 전송 타임스탬프를 등록하기 위한 수단과,
상기 등록된 전송 타임스탬프와 상기 기록된 수신 타임스탬프 간의 차이인 상기 프로브 메시지의 상주 시간을 계산하여, 상기 프로브 메시지 내의 필드에 기록하기 위한 수단과,
상기 계산된 상주 시간의 값이 다른 노드들 또는 상기 프로브 메시지의 현재 노드 후속 동작에 의해 중복하여 기록되는 것을 방지하기 위해 상기 프로브 메시지 내의 플래그의 값을 변경하기 위한 수단과,
상기 프로브 메시지의 상기 Time-To-Live의 값을 감소시키고 비교하기 위한 수단을 포함하는
네트워크 노드.
제 8 항에 있어서,
상기 프로브 메시지로부터의 정보가 복사된 프로브 응답 메시지를 생성하기 위한 수단을 더 포함하는
네트워크 노드.
제 9 항에 있어서,
상기 복사된 정보는 상기 계산된 상주 시간 및 상기 프로브 메시지의 식별자를 포함하는
네트워크 노드.
컴퓨터 및/또는 전용 시스템의 메모리 상에 저장된 명령어를 포함하는 컴퓨터 프로그램으로서,
제 1 항 내지 제 7 항 중 어느 한 항의 방법을 수행하도록 구성된
컴퓨터 프로그램.
제 11 항에 있어서,
입력은 네트워크 노드의 목적지 어드레스를 포함하는
컴퓨터 프로그램.
제 11 항 또는 제 12 항에 있어서,
입력은 상기 프로브 메시지 및 연관된 상기 프로브 응답 메시지의 전송에 대한 QoS(Quality of Service) 또는 서비스 종별(Class of Service) 사양을 포함하는
컴퓨터 프로그램.
제 11 항 내지 제 13 항에 있어서,
입력은 단방향 모드 또는 양방향 모드의 표시를 포함하는
컴퓨터 프로그램.
제 11 항 내지 제 14 항에 있어서,
제 1 항 내지 제 7 항 중 어느 한 항에 기재된 상기 프로브 메시지 및 연관된 상기 프로브 응답 메시지에 의해 트래버싱된, 네트워크 경로 내의, 적어도 하나의 네트워크 노드에서 단방향 또는 양방향의 상주 시간(들)을 표시하도록 프로그래밍된
컴퓨터 프로그램.